On Jul 27, 5:24 pm, Bill <[email protected]> wrote: > Not in order, it can't. The parent must know the children in order to > accomplish that.
Try putting some kind of index in the child - a time stamp or order field (100, 200...) > > Sounds like you have architected your solution to do too much in a > > single transaction which is just not performant (or possible) with the > > datastore. Time to re-think how you demarcate transactions. > > The idea that a single, simple bounds check is "too much" is ludicrous > -- especially given the fact that the datastore isn't doing this > bounds check automatically as would an RBDMS. Your blender doesn't do bounds checks either. Repeat: the datastore is not an RDBMS. The Google engineers have always taken care to point out this fact. > > The datastore is not an RDBMS. There are certain domain models which > > simply will not work on the datastore. If you cannot break down you > > data into small independent chunks your app will not work. > > At present I have a grand total of TWO entity classes, one of which > refers to the other by an indirect key. Pardon my language, but how > friggin' broken down does it have to be before it becomes anything > more than a toy?? You could make an infinitely complicated data structure with a single model class - it is the data *structure* that you need to be able to break down - not the model. You need to get a bit creative to find ways work within the capabilities of the datastore. > Fine. Meanwhile I'm demanding an answer from Google as to why this > sorry state of affairs. Max Ross, where are you? Demanding an apple to become an orange does not make it so. Not even Max Ross can pull that one off (I assume). > > 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. > this product will ultimately fail in the marketplace because > the costs of hacking a problem to fit your idea of a solution, rather > than adapting your tool to a problem, will be far too high. Looks like you've made your assessment. It is true that more time is required to make apps work with these restrictions. If this extra cost outweighs the other benefits then simply don't use the platform. For a large class of applications it already works very well and is improving at an amazing pace. -- 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.
