Re: For a deeper Indexed Database API (nested ObjectStores)

Hi Michaël,

I also implemented a filesystem solution on top of IDB:
https://github.com/ebidel/idb.filesystem.js/blob/master/src/idb.filesystem.js

It's a polyfill for the W3C Filesystem API [1]. The abstraction is nice
because it
takes away the hairy details (as you've encountered) of trying to use IDB
as a filesystem.

My approach was similar to Aaron's. There's only one database and one
object store.
Subfolders are implemented by saving files keyed off their fullPath and
cleverly using IDBKeyRanges.bound. Something like:

var DIR_SEPARATOR = '/';
var OPEN_BOUND = String.fromCharCode(DIR_SEPARATOR.charCodeAt(0) + 1);
var fullPath =  '/path/to/folder/';
IDBKeyRange.bound(fullPath, fullPath + OPEN_BOUND , false, true);

restricts the results in such a way that the keys that are returned only
fall under the
virtual "folder" /path/to/folder/.

Hope that helps. There's a demo here <Demo:
http://html5-demos.com/static/filesystem/idb.filesystem.js/demos/basic/index.html>
if
you're interested.

[1]: http://www.w3.org/TR/file-system-api/


On Mon, Apr 22, 2013 at 2:13 AM, Aaron Powell <me@aaron-powell.com> wrote:

>  It’s an interesting problem that you’re trying to solve and I’ve had a
> crack at my own implementation which you can find here -
> https://github.com/aaronpowell/indexeddb-filesystem****
>
> ** **
>
> A few implementation points:****
>
> **-          **I don’t think you want to split across multiple
> objectStores in your database, that’ll make it very slow to query as can’t
> build up indexes****
>
> **-          **My implementation is a flat structure which you have
> parent IDs tracked against each object so you’re building up a tree of
> sorts in your database****
>
> **-          **While I haven’t implemented it (at present) to get back
> the contents of a folder you would do something like:****
>
> ** **
>
> var transaction = db.transaction(storeName);****
>
> var store = transaction.objectStore(storeName);****
>
> var index = store.index(‘parent’);****
>
> var range = IDBKeyRange.only(<parent id>);****
>
> ** **
>
> index.openCursor(range).onsuccess = function (e) {****
>
>       //track items that the cursor gets****
>
> };****
>
> ** **
>
> **-          **You could also look at doing stuff like using array
> indexes to store the full parent path which you can then query across****
>
> ** **
>
> Anyway I might keep playing with my implementation to see how it turns out.
> ****
>
> ** **
>
> ** **
>
> Aaron Powell
> MVP - Internet Explorer (Development) | FunnelWeb Team Member<http://funnelweblog.com/>
>
> http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell |
> Github <http://github.com/aaronpowell/> | BitBucket <http://hg.apwll.me/>
> ****
>
> ** **
>
> *From:* Michaël Rouges [mailto:michael.rouges@gmail.com]
> *Sent:* Monday, 22 April 2013 5:31 PM
> *To:* public-webapps@w3.org
> *Subject:* For a deeper Indexed Database API (nested ObjectStores)****
>
> ** **
>
> Hello,
>
> I recently experimented with this API trying to simulate a file system,
> but I am sad to see a lack of depth.
>
> To preserve the environment applications using my tool, I want to create
> only one database for my filesystem.
>
> So I create my database, I add a table representing a folder and I save my
> files, until this point, it's ok.
>
> The design problem is when I have to simulate a subfolder ...
>
> I then create another database, but it does not seem very clean because
> the user of the application should be able to create your own folders,
> subfolders and files, and the application using my tool should also be able
> to create their own databases data ... there is therefore a risk of
> conflict.
>
> Using only one database should therefore go through the creation of a
> table folder or subfolder.
>
> Ok, it's doable ... However, it would ruin the performance, because when
> you open a database, the API returns an object containing the
> objectStoreNames property that contains the list of all tables in the
> database.
>
> Assuming that my file system contains thousands of folders and
> sub-folders, once the database is opened, the API will have to recover the
> full list, while operations to this file system in perhaps one or two
> concern.
>
> I can store objects in the records of my tables but this would retrieve an
> object that can be huge, again, while operations to this file system can be
> a concern or two.
>
> None of these solutions seem to me, at once, clean and optimal in terms of
> resources.
>
> My idea is that it may be more optimal to save a table in the fields of a
> record in another table and could overcome the lack of relationships.
>
> Since a picture is better than a long explanation, here is an example
> schema ObjectStores nested:
>
> indexedDB = {
>     database: {
>         directory_0: {
>             subdirectory: {
>                 // ...
>             }
>         },
>         directory_1: {
>             // ...
>         },
>         file_0.txt,
>         file_1.txt
>     }
> }
>
> For additional and / or feedback information, do not hesitate to contact
> me. ;)****
>
> Michaël****
>