2

I'm building a chrome app which requires a persistent and local database, which in this case can be either indexedDB or basic object storage. I have several questions before i begin developing the app:

  1. Is it possible to persist indexedDB data after un-installation of the chrome app and chrome browser?
  2. If the indexedDB file/data persist can i locate and view it?
  3. If I can locate but can't view it, is it possible to change the location of the indexedDB file?
  4. Can I store the indexedDB in a file located on desktop or any other custom location?
Shourya Sharma
  • 547
  • 4
  • 23
  • To that point @Shourya, if you are looking to persist the data outside the app, you can keep one copy in the app and using an iframe copy it to persist in on a web domain (think iFrame or like it using postMessage), this way you can "move" it. But in terms of the actual DB in the app, no, you do not have access to it at all, only the data in the tables. – joseeight Jan 22 '14 at 22:13
  • @joseeight i dont have the option to sync it with a remote server/google drive/web server. – Shourya Sharma Jan 22 '14 at 22:17
  • I see, so what are you really trying to do? I have dealt with storage in Chrome a lot and know for sure that you can't gain access to the database in a file form. But I can't see why you would want to do that for anyway. – joseeight Jan 22 '14 at 22:33
  • @joseeight i just want to make sure that the indexedDB persist even if I have to reinstall my app or chrome browser – Shourya Sharma Jan 22 '14 at 22:41
  • It is unclear to me how the data is stored, but the data for indexedDB is stored in `C:\Users\username\AppData\Local\Google\Chrome\User Data\Default\IndexedDB` on Windows, and inside that folder there are folders for each site with indexedDB. I don't think you can configure it to save elsewhere. – markasoftware Jan 23 '14 at 04:19
  • @Markasoftware the data for IndexedDB is stored in LevelDB-containing files – Dmitrii Sorin Jan 23 '14 at 05:52
  • i require the above functionality to import and export the database manually – Shourya Sharma Jan 23 '14 at 18:45
  • Be careful of IndexedDB reliablility: https://en.wikipedia.org/wiki/LevelDB. I don't know if it's still right. – Supersharp Oct 20 '15 at 14:32

3 Answers3

4

If I had these requirements, I see a couple of options that you might pursue

  1. Write a simple database backed by the FileSystem API, and periodically lock the database and back up that file. This would be pretty cool because I don't know of anyone who has implemented a simple FileSystem API backed database, but I could see it being useful for other purposes.

  2. Any edits to the database would be also made to a copy of the database stored on your backup server, and I would write functions that could import snapshots from your backup.

  3. Simply write functions to export from your indexedDB to some format into a backup, and to import from the backup.

All options seem quite time consuming. It would be cool if when you create an indexedDB, you could specify an HTML FileSystem API entry file to back it, and that way you wouldn't have to do 1 or 2.

I agree that it seems like quite an oversight that an indexedDB is quite difficult to back up.

kzahel
  • 2,765
  • 1
  • 22
  • 31
  • do you mean to say that i can put indexedDB in a file? – Shourya Sharma Jan 24 '14 at 18:27
  • No, but I am saying that it would be awesome if indexedDB were implemented in this way. However, it is not a part of the specification. It would be possible to implement your own database that uses a file for storage. – kzahel Jan 24 '14 at 19:50
  • Should I use the storage API to push the indexedDB data in an array and store it in a file or there's a better way to do it! – Shourya Sharma Jan 26 '14 at 20:19
2

I am writing a basic browser only application. No back end server code at this time. So I also have storage requirements. But I am not doing backup. I am looking at pouchdb as a solution: http://pouchdb.com/

Everything is looking good so far. They also mention that they would work well with Google Apps.

http://pouchdb.com/faq.html#native_support

The nice thing is you could sync your pouchdb data with a server couchdb instance.
http://pouchdb.com/api.html#replication

http://pouchdb.com/api.html#sync

If you want to keep the application local to the browser with no server support you could backup the entire database by using a batch fetch.

http://pouchdb.com/api.html#batch_fetch

I would run the result through gzip before you put it on the filesystem.

dodtsair
  • 178
  • 1
  • 6
0

I am currently attempting this very same thing. I am using the Chrome Sync File System Api (http://goo.gl/5q8Z9M), but running into some instances where my file (or its contents) is deleted. With this approach I am writing out a JSON object. Hope this helps.

c0d3rm0nk3y
  • 11
  • 2
  • we've got chrome.storage.sync, chrome.storage.local, indexedDB and WebSQL which is deprecated. out of which "sync" is the only one which i've tested to be persistent across re-installation. i needed to store a large amount of data so it left me with "local" for which chrome gives no api to store objects. it left me with no choice but to port my app to Adobe AIR. It was just a copy-paste thing(port-to-AIR). – Shourya Sharma Jan 29 '14 at 01:10
  • Good point, the sync does only allow so much space.. my initial thought was to use google drive to store the data itself, than pull it from there.. – c0d3rm0nk3y Feb 05 '14 at 15:30