# Convert from SQLite to IndexedDB

**URL:** <https://discourse.mozilla.org/t/convert-from-sqlite-to-indexeddb/13315>\
**Category:** Development\
**Created:** [January 31, 2017, 3:21pm UTC](https://discourse.mozilla.org/t/convert-from-sqlite-to-indexeddb/13315 "2017-01-31T15:21:04Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![kjemmo](https://avatars.discourse-cdn.com/v4/letter/k/439d5e/32.png) [@kjemmo](https://discourse.mozilla.org/u/kjemmo)\
**Post date:** [January 31, 2017, 3:21pm UTC](https://discourse.mozilla.org/t/convert-from-sqlite-to-indexeddb/13315/1 "2017-01-31T15:21:04Z")

</div>

I use SQLite in my overlay add-on and will need to switch to IndexedDB when I port to Webextensions.

Have anyone else done this who will share the steps needed.  
Do anyone know of any good documentation on how to make this switch.

Thanks.

---

<div class="post-metadata">

**Author:** ![NilkasG](https://avatars.discourse-cdn.com/v4/letter/n/0ea827/32.png) [@NilkasG](https://discourse.mozilla.org/u/NilkasG)\
**Post date:** [January 31, 2017, 4:08pm UTC](https://discourse.mozilla.org/t/convert-from-sqlite-to-indexeddb/13315/2 "2017-01-31T16:08:00Z")

</div>

I don’t have any personal experience, but this came up before. I’ll just quote myself:

> [@WebExtension APIs for SQL storage?](https://discourse.mozilla.org/t/webextension-apis-for-sql-storage/12224/2):
>
> If you want more SQL, this might be useful:  
> [GitHub - google/lovefield: Lovefield is a relational database for web apps. Written in JavaScript, works cross-browser. Provides SQL-like APIs that are fast, safe, and easy to use.](https://github.com/google/lovefield)
> 
> On a site note however, I have observed cases where I couldn’t use the indexedDB from a WebExtensions: A few month back IndexedDB would also be blocked for WebExtensions if it was blocked for web sites (privacy/storage settings). I don’t know if that is fixed.
> 
> The only reliable storage in therms of availability I know is `chrome.storage.local`. But that’s not really a database but rather a simple key/value storage that is written to a JSON file from time to time.

> I don’t know if that is fixed.

Nope, it isn’t.

---

<div class="post-metadata">

**Author:** ![kjemmo](https://avatars.discourse-cdn.com/v4/letter/k/439d5e/32.png) [@kjemmo](https://discourse.mozilla.org/u/kjemmo)\
**Post date:** [January 31, 2017, 10:13pm UTC](https://discourse.mozilla.org/t/convert-from-sqlite-to-indexeddb/13315/3 "2017-01-31T22:13:01Z")

</div>

Thanks for presenting an alternative.

But if possible I will stick as much to standards as possible.

Do one any have a link to bug with indexedDB, so I can track the progress?

---

<div class="post-metadata">

**Author:** ![NilkasG](https://avatars.discourse-cdn.com/v4/letter/n/0ea827/32.png) [@NilkasG](https://discourse.mozilla.org/u/NilkasG)\
**Post date:** [February 1, 2017, 12:51am UTC](https://discourse.mozilla.org/t/convert-from-sqlite-to-indexeddb/13315/4 "2017-02-01T00:51:50Z")

</div>

I have never filed a bug and haven’t searched for one either.

I have only encountered this bug with an extension I haven’t in my own personal profile, which i quite old by now - and packed with all kinds of privacy related add-ons and preferences.

To file a bug I would need to find out what is actually causing it, which would definitely take quite some time. The last time I did that it still took _month_ for the bug to be fixed (and I think that was more or less by accident too). So given my usecase, it seemed much quicker to implement a workaround.

---

<div class="post-metadata">

**Author:** ![kjemmo](https://avatars.discourse-cdn.com/v4/letter/k/439d5e/32.png) [@kjemmo](https://discourse.mozilla.org/u/kjemmo)\
**Post date:** [February 1, 2017, 5:15pm UTC](https://discourse.mozilla.org/t/convert-from-sqlite-to-indexeddb/13315/5 "2017-02-01T17:15:21Z")

</div>

Can anyone involved in the development of WebExtensions provide some info on this.

If indexedDB is the new standard and it is buggy, then that seems like a pretty important thing to fix.

It is not really encouraging to know that indexedDB is buggy before deciding to convert from SQLite.

Can anyone let me know if it is ‘safe’?

---

<div class="post-metadata">

**Author:** ![wbamberg](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/wbamberg/32/30597_2.png) [@wbamberg](https://discourse.mozilla.org/u/wbamberg)\
**Post date:** [February 1, 2017, 11:24pm UTC](https://discourse.mozilla.org/t/convert-from-sqlite-to-indexeddb/13315/6 "2017-02-01T23:24:36Z")

</div>

> [@NilkasG](#):
>
> On a site note however, I have observed cases where I couldn’t use the indexedDB from a WebExtensions: A few month back IndexedDB would also be blocked for WebExtensions if it was blocked for web sites (privacy/storage settings). I don’t know if that is fixed.

I’m not exactly sure what this refers to, but I did just confirm that if you disable indexeddb using the about:config preference “dom.indexeddb.enabled”, then WebExtensions can’t use it. Is that the issue you mean?

There is some interesting history here, where [this preference was made content-only](https://bugzilla.mozilla.org/show_bug.cgi?id=1079355), in part [so as not to break bootstrapped extensions](https://bugzilla.mozilla.org/show_bug.cgi?id=1122204).

I just asked in the #webextensions IRC channel, and the consensus from the dev team was that they’d agree to do the same for WebExtensions, so I [filed a bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1335919). I don’t think it would be a very high priority bug though (I guess because very few users would disable IndexedDB).

Will

---

<div class="post-metadata">

**Author:** ![NilkasG](https://avatars.discourse-cdn.com/v4/letter/n/0ea827/32.png) [@NilkasG](https://discourse.mozilla.org/u/NilkasG)\
**Post date:** [February 1, 2017, 11:35pm UTC](https://discourse.mozilla.org/t/convert-from-sqlite-to-indexeddb/13315/7 "2017-02-01T23:35:11Z")

</div>

I had already “dom.indexeddb.enabled” set to true (default) and my extension is definitely unable to use the indexedDB. So something else is causing it. I will try to find out what it is, but as I said, this is the kind of bug that takes time to track down.

> for WebExtensions, so I filed a bug

Certainly can’t harm anyway.

---

<div class="post-metadata">

**Author:** ![NilkasG](https://avatars.discourse-cdn.com/v4/letter/n/0ea827/32.png) [@NilkasG](https://discourse.mozilla.org/u/NilkasG)\
**Post date:** [February 2, 2017, 1:35am UTC](https://discourse.mozilla.org/t/convert-from-sqlite-to-indexeddb/13315/8 "2017-02-02T01:35:48Z")

</div>

Turns out that deleting `storage/default/*` in the profile folder solved the problem; restoring the folders from a backup also restores the problem.

This is a `tree /f` over the old `storage/default/`

```auto
├───moz-extension+++9446f127-0320-4a4d-913e-3e1e1738ac97
│ │ .metadata
│ │
│ └───idb
│ │ 1907939001voifdneIo.sqlite
│ │
│ └───1907939001voifdneIo.files
├───moz-extension+++c88ba4ee-c57e-4b9d-8c95-16469cf01c9d
│ │ .metadata
│ │
│ └───idb
│ │ 1907939001voifdneIo.sqlite
│ │
│ └───1907939001voifdneIo.files
└───moz-extension+++c93a0418-ac32-4dbb-af56-89640f5380b8
    │ .metadata
    │
    └───idb
        │ 1907939001voifdneIo.sqlite
        │
        └───1907939001voifdneIo.files

```

All files in these folders are at least half a year old.

And this is the new one after loading my extension (which has saved one `Blob` in a DB called `videoInfo`) and visiting `youtube.com` (which it works with)

```auto
├───https+++www.youtube.com
│ │ .metadata
│ │ .metadata-v2
│ │
│ └───cache
│ │ caches.sqlite
│ │
│ └───morgue
│ └───36
│ {13d62603-9b4c-4aa9-b65f-833117df8c24}.final
│
└───moz-extension+++bda124a5-abaf-4806-b364-b49c706780dc^addonId=%40youtubeoverhaul
    │ .metadata
    │ .metadata-v2
    │
    └───idb
        │ 1907939001voifdneIo.sqlite
        │
        └───1907939001voifdneIo.files
            │ 1
            │
            └───journals

```

I don’t see a correlation between the tow trees, but deleting the old files seems to unclog something. Deleting the new files and putting the old ones back reverts that.

I guess this can be categorized as “weird, but probably won’t happen again”.