On 12 Mar 2010, at 13:01, Scott Hernandez wrote:
We have a different idea about live systems and managing
upgrades/deployments. To answer the question below, you can always
upgrade the data in place because you will always need a way to load
that data into the current object representation. It just may be that
you need to take the system offline to migrate the data.
In my app taking the system off-line while re-processing the data is
not an option. The actual reprocessing can take days.
I see your point though. My data is mainly static so I don't have the
issues you describe of keeping the new version in sync with the live
version. However, I can think of several solutions to this while
still having the safety advantage of independent "tables" in the
datastore.
The simple way would be to, during the migration period, create both a
Person and a PersonNew whenever a user makes an edit.
Another way would be to do this transparently by creating a simple
"forked translator" that stored the Person as two Entities instead of
one. I won't go into details but it is certainly not a major extension.
I would probably go for the first method if it was just for my app -
but this is the kind of feature that could be pushed into the
framework to make it easier for others to benefit too.
The versions remain completely separate. Modifying live data in
place gives
me heart pains.
Duplicating data (during upgrades) is unacceptable, for my app. It may
be safer to leave the old data, but it is not always possible.
There is no maximum stored data on App Engine. If you delete the data
after one day is that still a problem?
I have
a *lot* of data, that was costly to generate (both in terms of network
and cpu) and to store. Jeff, and others on the Objectify list, have
spent a lot of time working on a solution with the goal of keeping the
app up during an upgrade (in simple upgrades), without needing to
migrate all the existing data first, which would require downtime.
Ok I understand. But that is a big trade-off - saving a day or two
worth of storage costs in exchange for testability, ability-to-revert
and the peace of mind that a coding error might corrupt your live data.
If the documentation was *very* clear about this maybe, but as Jeff
said, Hibernates biggest complaint was from new users who got LazyInit
exceptions. This is the same thing you have created, without the
benefit of having an exception. You may just get passed an instance of
an uninitialized object if you aren't careful.
Seems we have both claimed that in Objectify and Twig a careless user
could delete their own data. At the end of the day, you can never
guard against that completely in either framework.
That still does not mean that object activation is not an elegant
solution to the potential problem of loading too much data. But keep
in mind that this is not on by default - by default all data will be
activated.
I expect that most apps will not even use this feature but it is there
as an optimisation if needed.
John
--
You received this message because you are subscribed to the Google Groups "Google
App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
