I am not going to talk much about portability part. I believe everybody undestands that.. and some are ok with continuing with GAE datastore forever. But there can be changes in the APIs in later releases of GAE. Your code might working with later releases; but there can be better ways of doing the same thing in the new releases. By using low level APIs you might end up in suboptimal solution in that case. With a stanard like JPA , the risk of getting into this kind of situation will be less since with JPA the internal details are abtracted from the developers and GAE JPA implementation will be internally optimized with new releases.
Leaving portability part, I personally felt that use of JPA/JDO was much easier than using low level APIs. I had to spend couple of days before I could figure out how JPA works. But since I figured it out now, I can simply write Java code without bothering much about the underlying databse or the SQL/GQL/whatever it is. As a Java developers it is much easier for me to think in terms of classes and objects than tables and data in them. While fecthing the data, it is much easier for me to get it as a Java object which strongly typed against an entity which can have prop1, prop2 in one case and prop1 and pro3 in other case. In this hypothetical scenario, it might sound like a limitation. But if there is a case like that, as a Java developer, I would either create two different Java classes or create a Java class which has the superset of the fields that possible in all possible cases based whether the data is relevant. Alternatively I will use a Map and store such values as key-value pairs. (Since Map is not directly supported, I may create a array of objects of another class that contain the name and value fields or serialize it while storing the data) In case of large number if records in child objects, I beleive you can directly query based on the child object's class provided you know some unique Identfier for the child object which required even with low level APIs. Similarly, any other limitations on the JPA or JDO has a workaround and most of these will done while you are creating your basic set of Java classes. Once the hierarchy is created, I don't see any of the limiations will be encountered in runtime. Anyway, finally it is the individual developer's call on what he/she is comfortable with. And in some cases, we may have to choose a combination of different options based on what is best suitable for the scenario. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
