RE: [IndexedDB] setVersion is cra... is not good

On Sunday, July 17, 2011 1:46 PM, Jonas Sicking wrote:
> On Fri, Jul 15, 2011 at 5:55 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> > Jonas,
> >
> > We like the concepts and principles you are proposing.  It provides a more
> cohesive mechanism for enforcing/supporting upgrades and it leverages the
> existing concepts like "onversionchange" and "onblock" handlers which we
> are familiar with.
> >
> > Assuming we end up using: "IDBOpenDBRequest open (in DOMString
> name, in DOMString version);"
> > I would like to verify the side effects:
> 
> Is there a reason you're preferring to go with the version as a DOMString
> rather than as a integer as in my second proposal. I think using a string leaves
> a serious problem in that people could end up accidentally downgrading a
> database which could lead to things like dataloss. Though more likely is
> simply bad performance as when the downgrade happens, all other
> windows would if written properly close their connection to the database.
> 
> > 1. The new open API will eliminate the need for the setVersion API.
> 
> Yes.
> 
> > 2. The new IDBOpenDBRequest will eliminate the need for the
> IDBVersionChangeRequest interface.
> 
> Currently IDBVersionChangeRequest is used both for setVersion and for
> deleteDatabase. We certainly could use IDBOpenDBRequest for both, but
> onupgrade would never fire when deleteDatabase was called.
> 
> Another alternative would be to do something like
> 
> interface IDBBlockableRequest : IDBRequest {  attribute Function onblocked;
> }; interface IDBOpenDBRequest : IDBBlockableRequest {  attribute Function
> onupgrade; };
> 
> Where IDBBlockableRequest is what would be returned from
> deleteDatabase. But that might be a bit over engineered.
> 
> I'm fine with just having IDBOpenDBRequest if that is what people prefer.
> 
> > 3. Any time the version string in the open API doesn't match the current
> version string in the DB, the onupgrade handler will be called.  We probably
> should use a different name since this will apply to upgrade and downgrade
> (e.g. onversionchange).
> 
> This is another reason i'm suggesting using an integer for version instead and
> not having to deal with downgrading.
> 
> > 4. After the onupgrade handler is called, the onsuccess handler will be
> automatically called.
> 
> Yes. If the transaction created when calling the onupgrade handler is
> successfully committed then the onsuccess handler is called. If, however the
> transaction is aborted. The rules for when a transaction is aborted follows
> the same rules as we have for setversion-transactions today.
> 
> > 5. If the onerror handler is called (for the open API IDBRequest), the
> database will be in a closed state.  Devs will have to call open again with a
> different version to re-open the db.
> 
> Yes.
> 
> > 6. These changes won't affect IDBFactory.deleteDatabase or
> IDBDatabase.close.
> 
> Agreed. With possible exception for what type of request to return for
> IDBFactory.deleteDatabase. But the actual functionality remains unchanged.
> 
> > 7. The changes will affect the following method and interfaces only:
> IDBFactory.open, IDBDatabase.setVersion, and IDBVersionChangeRequest.
> 
> Yes.
> 
> > 8. Developers won't be able to update their schemas without changing
> their version string.
> 
> Yes.
> 
> > Our concern is the destabilization this will introduce in the current spec and
> the amount of time this could take to bake.  If we can scope these changes to
> be minimal and clearly define the areas of the spec that are affect that would
> ease our worries.  What areas of the spec do you expect will be affected by
> this change?  Our goal would be to minimize the side effects related to this
> change. How long before we can bake the concept enough to feel
> comfortable about its possible side effects?
> >
> > From our conversation with developers, they seem to be waiting for the
> IndexedDB spec to be locked before they start using the APIs.  It would be
> awesome if the first version of the spec was locked soon so developers can
> start relying on our APIs to start using the functionality. Do you feel this will
> be the last major change to the spec before we can start to lock it down?
> 
> I agree with all of the above. Would love to see agreement on this as soon as
> possible. We'd likely roll out the new API in firefox nightlies in a matter of
> weeks after there is agreement, and in released versions as soon as our
> release schedule allows us (12 weeks or so).
> 
> / Jonas

The reason I picked the string versioning approach was based in conversation I had with Pablo. He mentioned that using a number instead of string is a way of having the system impose policy on how databases are versioned.  One advantage of using strings is that they provide a mechanism to version using tags.  For example, my version could be a comma-separated list of tags that indicate which app features are present in the schema.  In addition, it could be used to help decide compatibility rules (i.e. backwards and forwards compatibility).  The approach seemed more flexible.

I'm okay keeping IDBVersionChangeRequest for deleteDatabase and IDBOpenDBRequest for the new open method.  This seems cleaner.

It would be great to hear Jeremy's opinion on this.

Israel

Received on Monday, 18 July 2011 17:21:06 UTC