- From: Israel Hilerio <israelh@microsoft.com>
- Date: Wed, 20 Jul 2011 20:33:24 +0000
- To: "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>, David Sheldon <dsheldon@microsoft.com>, John Hrvatin <John.Hrvatin@microsoft.com>
On Monday, July 18, 2011 10:50 AM, Jonas Sicking wrote: > On Mon, Jul 18, 2011 at 10:20 AM, Israel Hilerio <israelh@microsoft.com> > wrote: > > 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 definitely agree it's more flexible, but it's also more complex to use since > the page has to make sure not to accidentally downgrade the version. > > Would you have remembered to put the "am I downgrading" check in the > example I drafted in the initial email? > > There's also the problem of that if someone accidentally attempts to open a > database with an old version, that will likely result in any other page using > the database receiving a "versionchange" event which likely will disable the > page until the user reloads it (as generally "versionchange" happens at an > upgrade, at which point the page > *should* drop all database connections). > > So using a string also affects the user experience somewhat. > > > I'm okay keeping IDBVersionChangeRequest for deleteDatabase and > IDBOpenDBRequest for the new open method. This seems cleaner. > > The more I think about it, the more I like the simplicity of using > IDBOpenDBRequest for both, that way we have fewer request interfaces. > And looking at the HTML5 DOM it has plenty of onX attributes that will never > fire. > > But I'm totally fine with with going either way! > > > It would be great to hear Jeremy's opinion on this. > > Yes! > > / Jonas We're okay going with the numeric versioning approach you proposed. However, we have a couple of questions about the versioning scheme: * What is the granularity of the numbering scheme (i.e. float, int, unsigned shorts, etc.)? * What happens when the db is at version 1.3 and someone specifies version 1.0? Are we going to throw an error event or an exception? * Do we need to introduce a new error code (e.g. VESION_ERROR) to catch version problems? Also, how long and extensive do you expect the spec changes to be? Israel
Received on Wednesday, 20 July 2011 20:33:52 UTC