Rather than rail against jd's rather interesting straw men (I'm talking about data storage, not blenders, etc.) all I have to say is this: if it is "improving at an amazing pace" then it is my hope that this issue will be addressed and fixed by google so that it may continue to improve at an amazing pace. I don't see anything amazing about having to get creative to trick my tools into working.
If they need any help converting apples to oranges, let me see the source code. I'm happy to help. This is the heart of the matter: > > > In order to check that there is no existing entity with the same key > > > before writing an entity the load must be a part of the transaction or > > > another request could store an entity with the same key before you > > > committed - clobber. > > > Logically this absolutely does not hold water, if the retrieve > > operation falls within one entity group, and the insert/update happens > > in a completely different entity group. > > In that case they could not possibly have the same key... as you know > you must be dealing with entities in a single entity group. "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. To take an example from a recent email, consider the VERY SIMPLE case of Order-LineItem. Clearly, each LineItem belongs to the same entity group as its parent Order. No problem. Everybody always loves this example because it is so easy. It gives the illusion of system complexity without actually providing it. Then, consider the fact that each LineItem refers to a Product. The Product does not belong to the Order's entity group. It belongs to it's Catalogue's entity group instead. In order to insert the LineItem, you have to make sure the Product exists already. 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. 2. As such, the underlying datastore has no concept of data integrity. Okay, fine, I'll have to do the bounds checking myself. 3. I can't do the bounds checking within a transaction. Not because the result of the get would have anything to do with the upcoming insert, because of the lack of data integrity. Instead the datastore is making assumptions about data it has no control over. This isn't a failure of a datastore as compared to an RBDMs, this is a conceptual error. To misquote Steven Covey, you shouldn't try to manage implications of data outside your sphere of influence. It's bad practice. and as a kicker, 4. If I do the bounds checking outside a transaction, it's just as meaningless as if I did it within the transaction. What's the difference, since there are no foreign key constraints that would be violated if someone changed the result of the select? What, honestly, is the point in preventing it? "It is what it is because that's the way it is" is only an answer if we're dealing King Canute commanding the ocean tide to turn back. It is what it is because that's the way it's made. I'm asking for someone to rethink how it's made. Is that so unreasonable? -- 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.
