RE: Indexed DB + Promises
I’ve been maintaining an IDB wrapper using Promises for a few years now[1].
Some things I’ve learnt are:
· Sharing transactions are a pain, but can be beneficial
· Cursors would lead to a nicer implementation on generators
· Async looks like a nicer abstraction on top
· Transaction vs Request makes promises challenging
I’m going to take a bit more of a look into Joshua’s implementation when I get
a few moments as the above is my perspective from my approach so far.
[1] http://github.com/aaronpowell/db.js
From: Marc Fawzi [mailto:marc.fa...@gmail.com]
Sent: Tuesday, 29 September 2015 6:40 AM
To: David Rajchenbach-Teller
Cc: Joshua Bell ; public-webapps@w3.org
Subject: Re: Indexed DB + Promises
How about using ES7 decorators, like so:
@idb_promise
function () {
//some code that uses the IDB API in Promise based way
}
and it would add .promise to the IDB APIs
On Mon, Sep 28, 2015 at 1:26 PM, David Rajchenbach-Teller
mailto:dtel...@mozilla.com>> wrote:
On 28/09/15 22:14, Marc Fawzi wrote:
> <<
> Instead of having .promise to appended to the IDB methods as
> in `store.openCursor(query).promise` why couldn't you configure the IDB
> API to be in Promise returning mode and in that case openCursor(query)
> would return a Promise.
>>>
>
> I meant user configurable, maybe as a global config.
That sounds problematic. What if a codebase is modernized piecewise, and
only some modules have been made Promise-friendly?
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
RE: Starting work on Indexed DB v2 spec - feedback wanted
Speaking from the perspective of an IDB library author Promisification would be high on my list of wants as it was the primary driver behind my libraries existence. The next thing would be function expression filtering, again this is something that my library attempts to solve (https://github.com/aaronpowell/db.js/blob/master/tests/specs/query.js#L543-L552) but has to do it in user space. And to call out specific items from the IndexedDatabaseFeatures [1] it'd be Cancel versionchanged, Database Observers and batch-get's. [1] http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures Date: Sat, 19 Apr 2014 02:55:46 -0700 From: rayn...@gmail.com To: jo...@sicking.cc CC: dome...@domenicdenicola.com; jsb...@google.com; t...@creationix.com; public-webapps@w3.org; a...@microsoft.com Subject: Re: Starting work on Indexed DB v2 spec - feedback wanted > especially as your applicationgrows more complex or simply if the user has > your application open in two separate tabs. The two tabs use case is an interesting point. Currently as I understand the leveldb interface avoids this problem by saying "only one process can open a database". Not quite sure what the best way a low level interface can handle this. One valid option is to simply say "a database cant be opened by two tabs". This then requires a developer to use a cross tab communication channel to manually handle synchronization. This enables the default interface to be race free. On Fri, Apr 18, 2014 at 11:30 AM, Jonas Sicking wrote: On Thu, Apr 17, 2014 at 2:04 PM, Domenic Denicola wrote: > From: Joshua Bell >> How much of leveldb's API you consider part of the minimum set - write >> batches? iterators? snapshots? custom comparators? multiple instances per >> application? And are IDB-style keys / serialized script values appropriate, >> or is that extra overhead over e.g. just strings? > > This is my question for Tim as well. My personal hope has always been for > something along the lines of async local storage [1], but that omits a lot > of LevelDB's API and complexity, so presumably it goes too far for LevelDB > proponents. > > [1]: https://github.com/slightlyoff/async-local-storage A big question here is "do you need transactional integrity/atomic mutations?" These things will always make the API more complex and so it gets in the way if you don't need it. But not having them means exposing yourself to race conditions, especially as your application grows more complex or simply if the user has your application open in two separate tabs. My experience is that people need transactional integrity more often than they think they do. The API at [1] punts on transactional integrity entirely. It does not allow you to perform complex operations like "increase the value at 'unreadEmailCount' by one" in a race-free manner. / Jonas
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();
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.rou...@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
RE: What will be the query language for IndexedDb
But there is a query language, you've got indexes, bi-directional cursors, ranges, etc. Admittedly it's not a "Select * from ... " syntax but to me that would seem foreign on the web anyway. Constructing and executing an object model is more consistent with the other standards in the browser such as DOM interaction or the event model. Keep in mind that IndexedDB is very low level and provides the building blocks for library authors to provide the 'syntax sugar' as it were on top that better suites the way they want to/believe the API should be interacted with. My 2c on the matter anyway. 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: Rob VonNesselrode [mailto:rob_vonnesselr...@sitechcs.com] Sent: Thursday, 11 April 2013 11:54 AM To: public-webapps@w3.org Subject: What will be the query language for IndexedDb By all means take away WebSQL the database but you should then add SQL (the query language) to whatever you put in its place Without a standardised query language a data store is, well, just a bucket of bits. Whether it is "human readable", key-value paired or not Regards Rob von Nesselrode
RE: IndexedDB: undefined parameters
I believe it was part of the ES5 changes that brought this in, testing in both
Chrome (23) and IE 10 with the following code snippet:
var bar = function () {
undefined = 42;
var foo;
console.assert(foo == undefined);
}
bar();
That will always return true, meaning that undefined wasn't modified. This
means that it's safe to assume that undefined is undefined when passed into the
IDB API (as all browsers supporting IDB already implement ES5).
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: rgi...@google.com [mailto:rgi...@google.com] On Behalf Of Robert Ginda
Sent: Wednesday, 10 October 2012 9:19 AM
To: Boris Zbarsky
Cc: Alec Flett; public-webapps
Subject: Re: IndexedDB: undefined parameters
On Tue, Oct 9, 2012 at 3:11 PM, Boris Zbarsky
mailto:bzbar...@mit.edu>> wrote:
On 10/9/12 6:04 PM, Robert Ginda wrote:
But I never, ever use the symbol-known-as
"undefined" in script, since it's actually a write-able variable.
For what it's worth, it's not anymore. It used to be, but current ES makes it
a readonly non-configurable property of the global. Not sure to what extent
UAs have caught up with the spec on that.
Oh, I wasn't aware of that. I'd still avoid using undefined values to mean "I
intentionally don't want to provide a value". Null is more trustworthy for
that, because it's not going to show up "on accident". In my own private
coding guidelines in my head, I only *test* for undefined. It only appears as
an rvalue in very rare cases, and when it does it appears as "(void 0)".
Of course in cases like this:
function foo(undefined) {
// Code using "undefined" here loses
}
you still have a problem
I'd suggest also treating null as missing if possible.
In general, or for the specific IDB case?
Well my own personal opinion would be in general, but I don't know what kind of
repercussions that would have on other specifications and implementations.
Rob.
-Boris
RE: IndexedDB: undefined parameters
I'll agree that it is a bit on the confusing side, I'm pretty sure that there's
a point in the spec that it indicates that 'null' is how to represent a not
provided key but supporting 'undefined' would make it simpler to work with the
API. The problem I can see with that is there are several shipped
implementations of the spec that this would break for (if I recall correctly
IE10 will raise a DataError on undefined but not null).
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: alecfl...@google.com [mailto:alecfl...@google.com] On Behalf Of Alec Flett
Sent: Wednesday, 10 October 2012 8:52 AM
To: Boris Zbarsky
Cc: public-webapps@w3.org
Subject: Re: IndexedDB: undefined parameters
On Tue, Oct 9, 2012 at 11:37 AM, Alec Flett
mailto:alecfl...@chromium.org>> wrote:
On Tue, Oct 9, 2012 at 11:12 AM, Boris Zbarsky
mailto:bzbar...@mit.edu>> wrote:
On 10/9/12 1:52 PM, Joshua Bell wrote:
The IDB spec does not have [TreatUndefinedAs=Missing] specified on
openCursor()'s arguments (or anywhere else), so I believe Chrome's
behavior here is correct.
It looks correct as the spec is currently written.
It's not clear to me why the spec is written the way it is. It could just as
easily define that if the "any" value is undefined, it's ignored. Or it could
use [TreatUndefinedAs=Missing], indeed.
I have to say, as a developer it can be really frustrating to write
abstractions on top of APIs that behave this way, when you want to say
something like:
Someone asked me to clarify: by "this way" I meant "where passing undefined is
different than calling without the parameter" - meaning that in general, APIs
should behave the same if you call foo(undefined) as if you called foo().
Otherwise it's notoriously hard to write anything functional (in the CS sense)
around it.
Alec
var direction;
var range;
if (condition1)
direction = 'prev';
else if (condition2)
direction = 'prevuniq';
if (condition3) {
range = range1;
else if (condition4)
range = range2;
return source.openCursor(range, direction);
Alec
