On 12 Mar 2010, at 16:28, Jeff Schnitzer wrote:
You are increasing my suspicion that you've never actually performed
schema migrations on big, rapidly changing datasets.
You are increasing my suspicion that you like to make inflammatory
remarks without thinking them through just for the sake of trolling.
Perhaps cutting back on coffee might help ;)
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.
Actually, @AlsoLoad (in conjunction with @LoadOnly and the @PrePersist
and @PostLoad lifecycle callbacks) provides an enormous range of
ability to transform your data. I know, I've had to do more of it
than I would like to admit. You can rename fields, change types,
arbitrarily munge data, split entities into multiple parts, combine
multiple entities into one, convert between child entities and
embedded parts, etc
Firstly , I want to say that I can see advantages in "in-place"
updates in terms of CPU usage and storage. I accept that some apps
can have such huge amounts of data that this is the only practical
solution for them. When that is not the case - as in many apps - I
still stand by my point that keeping the new and old data types in
separate kinds has advantages.
I would like Twig to offer both techniques.
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.
This is cumbersome and inelegant compared to Objectify's solution.
Your perception of "elegance" is a little biased. Your solution
requires the developer to keep track of which fields in the *same*
entity belong to which version of your schema.
I would say that keeping separate versions is more elegant in terms of
simplicity and safety. But I agree that in-place updates have
advantages in terms of CPU usage and storage. I'll be thinking more
about ways to support in place schema changes in Twig.
You require the developers to 1) create a parallel hierarchy of
classes and
I would actually say that it is cleaner to have two separate classes
than two classes munged into one.
Batch gets are *the* core feature of NoSQL databases, including the
GAE datastore. Look at these graphs:
Batch gets *are* used in Twig - they are just not a part of the API.
But please - enough already about batch gets. This is a trivial
feature that I have said three times now will be included in the next
update when I add an update command.
There just hasn't yet been the need for them due to the non-central
roll keys play in Twig.
If you have a read-heavy app (and most are), nothing gives you
bang-for-the-buck like adding one little annotation and pulling your
data out of memcache instead of the datastore. Caching at higher
levels *might* save you some additional cpu cycles, but it's certainly
a lot more work.
The simplicity of having adding a single annotation to cache a type is
something that fits very well with the Twig philosophy of moving
complexity into the framework. It is definitely a feature that will
be added - I was just pointing out that its not hard to implement that
right now.
Jeff, no more coffee today - promise?
--
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.
