I think this sounds like a fine idea.
-Ben Turner
On Sat, Jun 21, 2014 at 5:39 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi all,
I found an old email with notes about features that we might want to put
in v2.
Almost all of them was recently brought up in the recent threads about
IDBv2
Mozilla is fine with removing the special |keyPath:| behavior.
Please note that this will also mean that step 1 of the algorithm here
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-extracting-a-key-from-a-value-using-a-key-path
will need to change.
We do want to
On Wed, Jan 18, 2012 at 1:16 PM, Israel Hilerio isra...@microsoft.com wrote:
We did some testing in FF and Chrome and found different behaviors:
Hi Israel,
Which version of Firefox did you test with?
Thanks,
Ben
On Wed, Jan 18, 2012 at 1:40 PM, Israel Hilerio isra...@microsoft.com wrote:
We tested on Firefox 8.0.1
Ah, ok. We made lots of big changes to key handling that will be in 11
I think. If you're curious I would recommend retesting with an aurora
build from
So it sounds like everyone agrees that accepting an empty array is not
desired... Can we just make that case throw an exception rather than
generating an empty transaction (which will then throw when it is
used)?
-Ben Turner
I think complete should be the correct type string.
-Ben Turner
I agree with Kenneth.
-Ben Turner
On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell k...@google.com wrote:
I prefer continuing to use an array for several reasons: simpler
syntax, better type checking at the Web IDL level, and fewer
ECMAScript-specific semantics.
-Ken
On Wed, Jun 8, 2011
it
rather than copy it.
Does that sound like what you were hoping for?
-Ben Turner
Firefox does lazily deserialize cursor values, so the slowdown you're
noticing is most likely due to us preserving the order of request
callbacks by queuing every continue() call in line with the rest of
the transaction. Jonas had proposed a faster, high performance cursor
that did not respect
Also, what should we do when you enqueue a setVersion transaction and then
close the database handle? Maybe an ABORT_ERR there too?
Yeah, that'd make sense to me. Just like if you enque any other
transaction and then close the db handle.
We don't abort transactions that are already in
It looks like I was wrong. Our current impl throws NOT_ALLOWED_ERR for
getting errorCode *and* result before readyState is set to DONE.
And now that I think about it I think I like that best. If we returned
NO_ERR from errorCode before DONE then it seems to imply that the
request succeeded when
I think generally avoiding throwing exceptions is a good thing. So for
.errorCode I would say returning unidentified or 0 is the way to go.
I would say we should add a code to IDBDatabaseException, NO_ERR = 0.
Or else indicate somehow that 0 is reserved for no exception. Then
return that from
Hm, Jeremy is right, If you want to look just at the transaction and
see why it aborted you can't rely on errorCode. Ick.
The only thing I'd change then is the abortMessage property. It's
easier to tell why your transaction aborted with the error code, and
I'd hate people doing string comparisons
Normal exceptions have error messages that are not consistient across
implementations and are not localized. What's the difference?
These messages aren't part of any exception though, it's just some
property on a transaction object. (None of our DOM exceptions, IDB or
otherwise, have message
(It's somewhat frustrating when they come back localized, but bearable.)
Sounds like what you really want is more specific error codes, not
really messages, right?
-Ben
Why not just expand our list of error codes to have multiple ABORT_
variants for each situation, and then always fire the abort event
with a slightly different errorCode?
That seems far simpler IMO.
-Ben
On Tue, Feb 8, 2011 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 7, 2011
I think that's what Ben was suggesting.
Yes. We already have ABORT_ERR, no reason we can't subdivide that
since it's being overloaded. In fact I think it makes perfect sense.
Add the following to IDBTransaction:
I'm really not a fan of making IDBTransaction more complicated. We
already have a
I'm actually fine with keeping the setVersion from proceeding until
the old database is collected. First, this is probably a bug in the
web page, and the page should be fixed. Second, the new database that
is waiting for setVersion to proceed will get an onblocked event, so
the page should know
Has anyone heard of or proposed any kind of use case where it would be
valuable to change the primary key of an object in the object store
(outside, or inside, a cursor)?
-Ben Turner
No, that idea was rejected a while ago. IndexedDB cursors are live, so
any change made during the cursor are visible to the cursor as well as
later queries.
-Ben Turner
On Tue, Feb 1, 2011 at 4:35 PM, Keean Schupke ke...@fry-it.com wrote:
Surely the cursor should be atomic, representing
The call to .continue() returns a IDBRequest (same one as was
originally returned from .openCursor()).
No... continue() returns void as currently spec'd and implemented in FF.
-Ben
Lastly, let's say you're doing cursor.continue() on an index cursor, how can
you get a handle to the objectStore? I believe you can't.
We gave IDBCursor a source property too, that either points to the
objectStore or index depending on who called openCursor.
-Ben
FWIW Jonas' proposed changes have been implemented and will be
included in Firefox 4 Beta 9, due out in a few days.
-Ben
On Fri, Dec 10, 2010 at 12:47 PM, Jonas Sicking jo...@sicking.cc wrote:
I've been reaching out to get feedback, but no success yet. Will re-poke.
/ Jonas
On Fri, Dec 10,
On Thu, Nov 11, 2010 at 8:07 AM, Jonas Sicking jo...@sicking.cc wrote:
The reason I specced it they way I did, with the lowest key always
being used, is that this way a NEXT_NO_DUPLICATE and a
PREV_NO_DUPLICATE cursor iterate the same entries. It seems unexpected
that reversing direction would
Actually, we could go even further and disallow paths entirely, and
just allow a property name. That is what the firefox implementation
currently does. That also sidesteps the issue of missing parents.
I'm not convinced that people are going to bury their key several
levels deep on the
Yes, let's have it tied to the instance on which setVersion() was called.
As Shawn pointed out that is consistent with the behavior that
database instances from different windows will observe. As Jeremy
pointed out that is consistent with the way object stores and indexes
are tied to a
? The worst case
is that the web app blinks up some message to the user to close other
windows, but it seems like that could happen even with an onblocked event
being added. Am I missing something here?
J
On Thu, Sep 23, 2010 at 9:57 PM, ben turner bent.mozi...@gmail.com wrote:
I'm voting
I'm voting for 1! I'd hate to give all the other requests a property
that only setVersion requests will use.
-Ben
On Thu, Sep 23, 2010 at 9:48 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Sep 23, 2010 at 2:43 AM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Sep 22, 2010 at 9:07 PM, ben
Hi folks,
While implementing the latest setVersion changes I came across this problem:
Let's say that a site is open in two different windows and each
decides to do a setVersion request at the same time. Only one of them
can win, obviously, and the other must end up calling close() on
itself or
Hi folks,
The spec currently says that IDBDatabase.transaction() takes an array
of object store names as its first parameter. While I think this is
fine I'd like to propose that we loosen that restriction and allow a
simple string to name one object store as well. Thus this code:
var
Hi folks,
While implementing the latest setVersion changes Jonas and I decided
that it would be really useful to be able to signal to the caller that
other web pages are open and using the database (thus preventing a
setVersion transaction from running).
Consider a web page open in two windows,
Hi folks,
We originally included IDBDatabase.objectStore() as a convenience
function because we figured that everyone would hate typing
|myDatabase.transaction('myObjectStore').objectStore('myObjectStore')|.
Unfortunately I think we should remove it - too many developers have
used the function
Sorry, I replied on the bug rather than to the list. Here's what I said:
Hm, I think the wording in the spec is bad, but I believe this bug is invalid.
The way we envisioned this for the async api is that calling continue() always
returns true (to match sync api, but it's really pointless) and
I am fine with removing it.
-Ben
Hi folks,
Currently there are only two ways to clear an object store of all
data: (i) remove the object store and recreate it, or (ii) open a
cursor and call remove for all entries. I propose a third, simpler
approach:
interface IDBObjectStore
{
...
void clear();
...
};
Any thoughts?
On Tue, Aug 3, 2010 at 12:20 PM, Jonas Sicking jo...@sicking.cc wrote:
I think there is a bug in the above proposal though. clear() should
return a IDBRequest. However the .result of the request should likely
be null.
Yes, definitely. My fingers were too fast for my brain.
-Ben
On Wed, Jul 14, 2010 at 3:10 AM, Jeremy Orlow jor...@chromium.org wrote:
For example, with dynamic transactions you can get into live-lock
situations.
I'm particularly opposed to dynamic transactions for just this reason.
We would clearly have to throw an exception or call the error callback
if
I think I would be happy just removing the _NO_DUPLICATE directions.
As Jeremy noted it is quite easy to emulate and it would then be up to
the webapp author whether she wanted the first or last duplicate
value.
-Ben
On Wed, Jun 30, 2010 at 11:56 PM, Jonas Sicking jo...@sicking.cc wrote:
On
I think I would be happy just removing the _NO_DUPLICATE directions.
As Jeremy noted it is quite easy to emulate and it would then be up to
the webapp author whether she wanted the first or last duplicate
value.
-Ben
On Wed, Jun 30, 2010 at 11:56 PM, Jonas Sicking jo...@sicking.cc wrote:
On
I would also point out that throwing exceptions at the call site makes
debugging much easier in my opinion. Our error events currently don't
include information like filename and line number where the failing
request was generated (though I think we should add that eventually).
Exceptions are much
I would also point out that throwing exceptions at the call site makes
debugging much easier in my opinion. Our error events currently don't
include information like filename and line number where the failing
request was generated (though I think we should add that eventually).
Exceptions are much
Hi folks,
We've hit a bit of a snag implementing put() for autoIncrement'ing
objectStores when using inline keys. Consider this:
Spec text from
http://dev.w3.org/2006/webapi/WebSimpleDB/#dfn-steps-for-storing-a-record-into-an-object-store
5. If key is not defined or null, then perform the
On Tue, May 11, 2010 at 11:10 AM, Jeremy Orlow jor...@chromium.org wrote:
I agree this is a problem and I largely agree with your solution. My only
concern is performance of cloning data which will (in most cases) not even
be used. I wonder if the result of put should (instead of being the
On Tue, May 11, 2010 at 11:10 AM, Jeremy Orlow jor...@chromium.org wrote:
No matter what, I think we shouldn't have the semantics of the sync and
async APIs differ in such a subtle way: if the async API returns a clone +
the generated number as its result, then the sync API should as well (vs.
Hi folks,
We've been playing around with the async API and have made some
changes to the IDBRequest interface that we'd like feedback on and
hopefully inclusion in the spec. Here's what we have now:
interface IDBRequest : EventTarget {
void abort();
const unsigned short INITIAL = 0;
Hey folks,
I'm working with Shawn on the Firefox implementation. Here's our idea
as of now, would you all please comment about things you like or
dislike? Hopefully this follows the gist of the comments shared
already.
interface IndexedDatabaseRequest {
IDBRequest open(in DOMString name,
Hey folks,
I'm working with Shawn on the Firefox implementation. Here's our idea
as of now, would you all please comment about things you like or
dislike? Hopefully this follows the gist of the comments shared
already.
interface IndexedDatabaseRequest {
IDBRequest open(in DOMString name,
47 matches
Mail list logo
