On Wed, Jan 27, 2010 at 3:28 PM, datanucleus <[email protected]> wrote: > > I only represent JDO, as a spec, not how GAE/J have implemented it. > The docs for that are provided in the JDO spec and on the DataNucleus > website. I fail to see anything controversial in how they are > represented in those places. I've already made my feelings well enough > known on exposing environment specific classes into user space
This response (which I have seen repeated many times on this list) is deeply unsatisfying. "JDO is wonderful, the problem is just the implementation!" Sounds a bit like socialism. It certainly does no good for the original poster. I think there's a problem with JDO in general - it tries to be a universal data access API, but really only gets 85% of the way there. BigTable is something different, and the old mapping annotations are (yet again) insufficient, so you need extensions like gae.unindexed and twisting the query language to support batch queries. Every time something different comes up, JDO annotations expand and now it's full of what feels like cruft. Half of DataNucleus' features don't apply to BigTable, and several significant aspects of BigTable aren't handled by JDO. I reposit my earlier question, how can you configure - in JDO - the three different one-to-many representations that BigTable supports, all of which have differing performance and transactional characteristics: 1) A one-to-many relationship stored as a Photo key array in the Album entity 2) A one-to-many relationship stored as an Album key in the Photo's key parent 3) A one-to-many relationship stored as an Album key property in a Photo entity It won't be on the DataNucleus website because these are specifically BigTable representation issues. It's not in the GAE/J docs. My guess is that at least one of these three representations requires Key manipulation by the user. > And you forgot @GeneratedValue to get the equivalent thing, so not > really any different. So you have shorter names, but then you have an > IDE too that adds them with completion, so what difference is that? Length is irrelevant. Being able to be read and understood easily without digging through piles of documentation on three different websites is essential. In this respect, JDO is awful. > Either way, if you think you can make some improvements and really > want to effect a standard then the Apache JDO group is waiting to hear > from you My goal is to create a simple interface that allows users to conveniently access the power of BigTable with the shortest possible learning curve. Your goal is to create a grand unified API which allows nearly any entity graph to be represented on nearly any concrete datastore. Our goals are not compatible. Jeff -- 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.
