I think your observations about how local databases with a version specific structure (distinct from the application code) complicates things is very correct. One approach taken by some apps has been to have the new application code migrate existing local databases to the new schema upon first use. So upgrade the local databases after the application code updates. There is an indirect means to enable/disable autoupdate. Once a version has been successfully downloaded, set the manifestUrl to a url which always returns a 304 response, autoupdates will start but quickly find nothing todo.
Given that, another approach could be for application code to detect when a new version is available thru some other means (like fetch the real manifestUrl and compare it's 'version' attribute to store.currentVersion). Application code could create and populate a new upgraded database in the background, and when ready reset the store's manifestUrl and call CheckForUpdate explicitly, and upon update completion reset the manifestUrl back to the 304 generator. I don't think Gears (or HTML5) has a good handle on this aspect of things or what the best practices are. On Thu, Nov 6, 2008 at 3:27 AM, sobolanul <[EMAIL PROTECTED]> wrote: > > Hi. > > I think that the auto update feature of the ManagedResourceStore could > be bad in some cases. I think an option to enable/disable this option > on the fly would be need it. > > As is stated in docs: "An automatic update is started each time Gears > intercepts and serves a request from a ManagedResourceStore". > > Example when this is bad. > > There is an application with offline functionality that is working > fine. User X comes and syncs all his data (that is a coplex data > collection with lots of offline code and a complex database > structure). Next day, a major update is done to the the application, > update that changes entirely the db structure and way how data are > handle. On the server side was written code that will support > synchronization with the older versions of the code. Offline mode is > composed from 2 big parts: offline database and offline code (mainly > javascript code, stored in js files). After the update, server > supports synchronization with old code/db and new code/db. But when > user X enters again on the site, (he is now connected to internet), > ManagedResourceStore will get the new js files automatically and when > he tries to sync to online all will crash, because old DB with new > code is not working. Due the complexity of the changes, converting > offline data to new data on local machine is nearly impossible. > > This is why I think that an option to disable autoupdate would be > nice. What you think? I am missing something? >
