W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [IndexedDB] setVersion with multiple IDBDatabase objects

From: ben turner <bent.mozilla@gmail.com>
Date: Tue, 28 Sep 2010 08:19:22 -0700
Message-ID: <AANLkTimViC8bx0MTF6r5rs-Y4n0WUAb23+F_72qX_ATV@mail.gmail.com>
To: public-webapps WG <public-webapps@w3.org>
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 instance. Also, the |event.source| will be
db1 in the given example, so it seems natural to allow changes only to
the database we pass in the event and no other.

-Ben

On Tue, Sep 28, 2010 at 8:00 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> I guess I should have mentioned that I too am in favor of it being tied to
> an instance.  I think this matches the model we use elsewhere in terms of
> transactions being tied to specific objectStore and index instances.
> J
>
> On Tue, Sep 28, 2010 at 3:47 PM, Shawn Wilsher <sdwilsh@mozilla.com> wrote:
>>
>> On 9/28/2010 7:42 AM, Jeremy Orlow wrote:
>>>
>>> What do we want to do if the user calls window.indexedDB.open("myDB",
>>> "some
>>> description") twice and stores the result as db1 and db2, calls
>>> db1.setVersion(), and then in the success handler does
>>> db2.createObjectStore?  In other words, is the setVersion transaction
>>> tied
>>> to the database instance that setVersion was called on, or is it
>>> available
>>> to any instance/object that points to that particular database for that
>>> particular origin in that particular page/worker?
>>
>> While I can see an argument either way, I think I'd prefer it to be tied
>> to the instance.  I like this because then it works the same as it does
>> being in different windows.  I don't have a strong opinion on this though.
>>
>> Cheers,
>>
>> Shawn
>>
>
>
Received on Tuesday, 28 September 2010 15:20:12 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT