Thank you for your response. I know that migrations for local DB would do the job, but there are cases when the code/db changes are so big that the converting local sored code/db to new versions is nearly impossible. This is why I have implemented on server side code that can handle the old code/data format and new code/date format.
Solution that I implemented it was to modify the manifest url after application is in offline state (I know if the application is in on/ off line status even if there is an internet connection available) to go to an invalid page. This solve the problem because the coed will not be updated for local apps until they came online, but looks strange to solve a problem by generating an error. This is why I think that a new option to the store would be nice. Something like "readwrite attribute boolean autoUpdateEnabled". What you think? Is there any chance to such a feature to be implemented? Eduard On Nov 6, 10:11 pm, Michael Nordman <[EMAIL PROTECTED]> wrote: > 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?
