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

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://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

Received on Monday, 22 April 2013 09:13:47 UTC