On 26 Jul 2010, at 19:21, Bill wrote:
Good thought, but unforunately Elements already have a parent key in
this manner. Elements are hierarchical, so that an Element's parent
is another parent.
Can an entity have more than one parent? I haven't tried that...
An Entity can only have one parent as it is encoded into its key as a
path of ancestors leading back to the root entity.
Are all Element "trees" in the same domain? If so then you could make
Domain implement Element and use it as the root of an element
hierarchy. But this limits the concurrency of changes to Elements to
a few writes per second per Domain.
Do you update more than one element in a transaction? If not then an
unowned relationship between entities would be fine.
Are domains added and removed often? If not then is it sufficient to
check that the domain exists before working on your elements outside
of the transaction? Just never delete Domains - mark them as deleted
instead.
Your original problem "Cannot operate on more than one...." was caused
by trying to load an element in a different entity group. Even load
operations on a non existent entities (e.g. Domain) are included in
the transaction. That is how you can guarantee you don't clobber
existing data when you do a put(...) in a transaction.
You can think of starting a transaction as creating a timestamp on the
root entity - any changes to any element in the entire entity group
after that time and before the commit will cause a concurrency
exception. I think of transactions on non-existing roots as making a
kind of temporary place-holder root to which the timestamp is added.
See this for more details:
http://www.youtube.com/watch?v=tx5gdoNpcZM
If non of those work arounds is sufficient then perhaps you need
distributed transactions. The Slim3 project implements distributed
transactions using the task queue and there was a project with the aim
of making a generic solution:
http://www.youtube.com/watch?v=IOtBlzsx0m8
Not sure what happened to that though.
It is possible that you need a full RDBMS - in which case you will
either need to patiently wait for the release of the App Engine one
recently announced or run your own on a hosted server. Just don't
expect the same scalability as you get from the datastore.
--
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.
