On 27 Jul 2010, at 21:18, Bill wrote:
"That's the way it is because that's the way we say it has to be" is not an answer. There is no reason why selecting an object from one group is going to impact insert or update in a different entity group
It doesn't! You just cannot do it in the same transaction like you are trying to. Do it outside of the transaction or in a different transaction.
In order to insert the LineItem, you have to make sure the Product exists already.
Not if you know it exists before the transaction and will not be deleted
End of story. There's no way around this. In an RBDMs world, this would be accomplished by foreign key constraints. The GAE datastore can't do this. That's fine. I'm prepared for that. That's not what I'm complaining about. What I'm complaining about is really in three parts: 1. The LineItem can't contain a direct reference to Product. Product is not part of the LineItem entity group. Not a huge problem, becuase I can just use a key instead.
If you use Twig it can - it supports unowned direct relationships. In fact in Twig you would probably be best to model the entire LineItem collection as @Embed'ded which will fetch the whole bunch in a single entity
2. As such, the underlying datastore has no concept of data integrity. Okay, fine, I'll have to do the bounds checking myself.
The reality is that "bounds checking" is expensive and not friendly to distributed environments.
. I'm asking for someone to rethink how it's made. Is that so unreasonable?
Check out the Google I/O talks "distributed transactions" and "transactions across data centers" - you will see that there might be more to this than you assume.
-- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
