I think this sounds like a fine idea.
-Ben Turner
On Sat, Jun 21, 2014 at 5:39 PM, Jonas Sicking 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 abou
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 co
On Wed, Jan 18, 2012 at 1:40 PM, Israel Hilerio 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 https://www.mozilla.org/en-US/firefox/aurora.
Thanks for the
On Wed, Jan 18, 2012 at 1:16 PM, Israel Hilerio 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
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 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, J
=) then we'd transfer 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 this
>> 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 th
> 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 fro
> (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
> 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
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
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 tha
> 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
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 wrote:
> On Mon, Feb 7, 2011 at 8:05 PM, Je
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 wrote:
> Surely the cursor should be atomic, representing the instant in t
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
>> 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
> 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
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 wrote:
> I've been reaching out to get feedback, but no success yet. Will re-poke.
>
> / Jonas
>
> On Fri, Dec 10, 2010 at 4:33
On Thu, Nov 11, 2010 at 8:07 AM, Jonas Sicking 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 return dif
> 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 docum
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 transaction
t
> assume it's blocked until it receives a onsuccess message? 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
>
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 wrote:
> On Thu, Sep 23, 2010 at 2:43 AM, Jeremy Orlow wrote:
>> On Wed, Sep 22, 2010 at 9:07 PM, ben turner wrot
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, o
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 transactio
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 t
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 wit
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 the
I am fine with removing it.
-Ben
On Tue, Aug 3, 2010 at 12:20 PM, Jonas Sicking 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
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?
-Ben
On Wed, Jul 14, 2010 at 3:10 AM, Jeremy Orlow 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 we detect liveloc
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
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 wrote:
> On Wed, Jun 30, 2010 a
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 wrote:
> On Wed, Jun 30, 2010 a
On Tue, May 11, 2010 at 11:10 AM, Jeremy Orlow 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.
> modifying the o
On Tue, May 11, 2010 at 11:10 AM, Jeremy Orlow 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
> structured clone
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 fol
erwrite defaults to false for put operations
> on an object store. Ben Turner and I have been discussing changing the
> default of put to not allow overwriting by default. We feel this is better
> behavior because simply omitting the flag should not result in destroying
> data. Put
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,
48 matches
Mail list logo
