ManagedResourceStore auto update is bad?

[sobolanul]

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?

[Michael Nordman]

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.

[sobolanul]

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 <micha...@google.com> 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.
>