Okay, time to chime in. There are some pretty different philosophies
driving these frameworks.
On Fri, Mar 12, 2010 at 4:56 AM, John Patterson <jdpatter...@gmail.com> wrote:
>
> On 12 Mar 2010, at 05:45, Jeff Schnitzer wrote:
>
> How, in Twig, do you rename a field?
>
> I'm glad you brought this up. I've found simple renames are better handled
> at the low level - no need to rehydrate them into instances just to rename a
> property.
> But for typesafe changes large or small Twig supports data migration in a
> much safer, more flexible way than Objectify. Read on for details.
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. Objectify's
goal is to not require taking your system down to make data (schema)
changed.
> Cool, the @AlsoLoad is quite a neat feature. Although very limited to
> simple naming changes and nothing structural. All this is based on a
> dangerous assumption that you can modify "live" data in place. Hardly
> bullet proof.
> The Twig solution is to create a new version of the type (v2) and process
> your changes while leaving the live data completely isolated and safe. Then
> after you have tested your changes you bump up the version number of your
> live app.
> So basically:
> 1 - Create your new class PersonNew and set its version to 2
> @Version(2)
> class PersonNew {
> int age;
> String fullName;
> }
> 2 - Configure the "Kind name" to be the same e.g. "P" (short kind names save
> DS space)
> 3 - Load your old Person instances and for each store a new PersonNew
> instance.
> Your data is now upgraded.
> 4 - Now you can just replace Person with PersonNew in your code and deploy a
> new version.
> 5 - Test the version. This crucial step is not possible with Objectifies
> solution.
> 6 - Only when you are happy your changes are correct make the new version
> live. The new data version will be used and you can delete your old data
> when you want.
> So you see the Twig method of data migration is much safer than Objectifies.
> It has the following advantages:
> 1 - You don't eve have a "half-updated" schema
> 2 - Tt works for major structural changes rather than just trivial field
> renames.
> 3 - You can test the new data structure before going live
> 4 - You can revert back to you old data structure
> 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. 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.
Testing is important, but either way you need to transform the data
from the old schema to the new schema, with code. Objectify gives you
ways to do this with a live system. It means you can run in a
configuration with various schemas of data (stored instances) that all
transform to the current (live) version. It may be that you change the
schema so much that you must take the system off-line to migrate data
(mostly related to getting your queries working across schemas), but
maybe not.
[snip]
> Hollow, stateful entities with lifecycles are pretty magical.
> Cascading loads and saves are pretty magical. POJOs and Keys are
> simple.
>
> There really is nothing magical about an uninitialised instance. Sounds
> like you are just on a witch hunt.
> John
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.
Wooppsss. Why is my data gone?... Oh, I passed the wrong
(uninitialized) object around, and then saved it.
--
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.
