Comments on: The Google App Engine Data Model http://bolour.com/blog/2009/06/the-google-app-engine-data-model/ Sat, 06 Mar 2010 14:06:10 +0000 http://wordpress.org/?v=2.8.4 hourly 1 By: Kevin http://bolour.com/blog/2009/06/the-google-app-engine-data-model/comment-page-1/#comment-9839 Kevin Sat, 06 Mar 2010 14:06:10 +0000 http://bolour.com/blog/?p=29#comment-9839 I value your clear, concise introduction to the GAE Datastore, as accessed through JDO/JPA. Thank you. I value your clear, concise introduction to the GAE Datastore, as accessed through JDO/JPA. Thank you.

]]> By: Dan http://bolour.com/blog/2009/06/the-google-app-engine-data-model/comment-page-1/#comment-9836 Dan Fri, 05 Jun 2009 14:04:33 +0000 http://bolour.com/blog/?p=29#comment-9836 Thanks for the answer. Thanks for the answer.

]]> By: Azad Bolour http://bolour.com/blog/2009/06/the-google-app-engine-data-model/comment-page-1/#comment-9835 Azad Bolour Wed, 03 Jun 2009 16:02:49 +0000 http://bolour.com/blog/?p=29#comment-9835 In answer to Dan: The limitation on transactions is specified in terms of entity groups, which are logical constructs, specified in the terms of the logical model of hierarchies. So the developer does not have to know the implementation details to understand this limitation and work around it. But most developers I know have a need to see a justification for such a drastic limitation, and that is where some of the implementation details help. The fact that data is distributed is not directly exposed at the API level, but it is not that far from the surface, at least for now. In answer to Dan: The limitation on transactions is specified in terms of entity groups, which are logical constructs, specified in the terms of the logical model of hierarchies. So the developer does not have to know the implementation details to understand this limitation and work around it. But most developers I know have a need to see a justification for such a drastic limitation, and that is where some of the implementation details help. The fact that data is distributed is not directly exposed at the API level, but it is not that far from the surface, at least for now.

]]> By: Dan http://bolour.com/blog/2009/06/the-google-app-engine-data-model/comment-page-1/#comment-9834 Dan Wed, 03 Jun 2009 04:16:04 +0000 http://bolour.com/blog/?p=29#comment-9834 I wasn't clear in my prior comment. What I meant was that some implementation details seemingly need to be understood by those who program against GAE. An example of such a detail is the fact that "transactions are limited to individual entity groups", which Azad points out. Does the fact that an exception is raised mean that the developers has to understand that entity groups stay close together at all times? Or can the abstraction hide that fact, and present a higher level reason why transactions are limited to individual entity groups, which can be gradually relaxed as GAE comes up with a better implementation. I think it's trying to do the latter. I wasn’t clear in my prior comment. What I meant was that some implementation details seemingly need to be understood by those who program against GAE. An example of such a detail is the fact that “transactions are limited to individual entity groups”, which Azad points out.

Does the fact that an exception is raised mean that the developers has to understand that entity groups stay close together at all times? Or can the abstraction hide that fact, and present a higher level reason why transactions are limited to individual entity groups, which can be gradually relaxed as GAE comes up with a better implementation. I think it’s trying to do the latter.

]]> By: Dan http://bolour.com/blog/2009/06/the-google-app-engine-data-model/comment-page-1/#comment-9833 Dan Tue, 02 Jun 2009 19:58:13 +0000 http://bolour.com/blog/?p=29#comment-9833 It'd be too bad if Google designers and developers realize later on that the very same demands that led users of hierarchical databases to move to relational databases will lead GAE data stores to evolve in similar ways, leading the GAE customer's code to develop along the same paths, rewritten as it evolves to new data models. Also I find it a little disturbing that implementation details (i.e. not dividing into separate servers). Should we be working at an abstraction level above that? Is that something that's explicitly stated in the entity groups definition, or just an artifact that was mentioned during the GAE talks? It’d be too bad if Google designers and developers realize later on that the very same demands that led users of hierarchical databases to move to relational databases will lead GAE data stores to evolve in similar ways, leading the GAE customer’s code to develop along the same paths, rewritten as it evolves to new data models.

Also I find it a little disturbing that implementation details (i.e. not dividing into separate servers). Should we be working at an abstraction level above that? Is that something that’s explicitly stated in the entity groups definition, or just an artifact that was mentioned during the GAE talks?

]]>