I believe there are a lot of reasons and use cases not to go the JDO/ JPA way and look for a light weight solution. I came up with a similar idea like Nacho and created a simple class to persist Java objects using the low-level API. However I consider my code not being in a state yet for publising it. I also agree that this initiatives/ideas should not claim to be a replacement for JPA/JDO. It is simply an alternative. In the situation where I not even can write a file something as simple like a file might be attractive. Also it seems to me that JPA/JDO is tight to the relational model and the datastore is not. Java is not either. So going from Java to the relational model and the mapping back to a non-relational somehow seems to be odd. JPA/ JDO would be attractive to hide if there is a non-relational or relational store to a Java developer. Just provide the annotations/ configuration and do not care about the characteristics of the store. But looking at all the limitations I doubt that it will ever work like this. I am eager to follow this discussion and as you said: at the end we will benefit all from sharing thoughts and ideas how we can improve things.
Jens --~--~---------~--~----~------------~-------~--~----~ 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-java@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 -~----------~----~----~----~------~----~------~--~---
