Re: [appengine-java] Re: JPA/JDO vs low level API
As Jeff and others already posted, JPA on AppEngine just don't work as you expect (from the JPA point of view), and others just work as you don't. I'm the team leader of a running GAE/J application and we are, like Jeff says, * screaming* because of my decision to use JPA. We were about to consider using JDO, due to it's non-RDBMS options, but looks like the best choice is another tool like Objectify or Twig-persist. We are now trying out those tools to do come poof-of-concept in our codebase. A good choice is to encapsulate your datastore using a DAO or Repository pattern (or even both!), since they may help you to change your mind in the future. We did it and now we can try out some other tools on top of the Low Level API. In regards of the Objectify library, +1 for the helpers on schema migration. This is very (very!) hard to acomplish on a real-world web app when using JDO/JPA, and is a very usefull feature. In any case, now the RemoteApi is also available in Java (as per 1.4.4) and this is very useful to do some data export, local fixture loading and others. So, it is nice to at least know how the datastore works, it may help you in the future. -- 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.
Re: [appengine-java] Re: JPA/JDO vs low level API
It's a mixed bag with regards to Google internal projects. There are folks using JDO/JPA, and there are folks who go straight to the Low-Level API. I spoke with one internal team who mentioned an interest in Objectify but were concerned it could be abandoned because they had had a similar experience with appengine-patch for Django. Next time I see those guys, I'll let them know that the Objectify community seems to be thriving. The Slim3 community is also doing pretty well, but it seems like most of the useful posts are in Japanese. Ultimately, that's the risk you run with any kind of software. At least if it's open source, you can pick at it and keep the bits you need running. I'm personally hoping we can better support framework developers and just keep the Low Level API very tight and consistent. Ikai Lan Developer Programs Engineer, Google App Engine Blog: http://googleappengine.blogspot.com Twitter: http://twitter.com/app_engine Reddit: http://www.reddit.com/r/appengine On Wed, Apr 6, 2011 at 6:58 AM, Andrew andrew.w.d...@gmail.com wrote: I couldn't agree more with Jeff. JDO/JPA on GAE is pants for any real project. I am part of a 4 person development team that recently completed a fairly hefty 6 month GAE project built using GAE, GWT and Guice. We used JDO/Datanucleus for the persistence technology which caused significant problems across the project. As well as the issues that Jeff points out, simple things like IDE integration (predominantly Eclipse) with Datanucleus never seemed to work very well. Getting transaction demarcation to work with how the store 'actually' works is also practically impossible. We burnt a lot of days getting around a mass of silly little issues for no real benefit. To be clear, in standard relational environments we'll use Hibernate (et al) almost exclusively as an ORM, but, in my view, trying to use JDO/JPA on GAE is at this point in time a frivolous exercise that ultimately will heavily limit what you can do on the platform (not discounting the great work done be those that did port the standard over). It also lures you into this familiar relational way of looking at persistence problems which really does not, in any way, translate to how the datastore actually works. I'd be very interested to know how Google's internal projects work with the store -- as presumably, it's going to be a fairly similar interface -- but, if we were starting from scratch, I'd lobby very hard for using the low-level API on its lonesome (it's already a pretty clean service). On Apr 5, 6:22 pm, SkYlEsS shou...@gmail.com wrote: Thanks you so much for all this responses everybody ! -- 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. -- 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.
[appengine-java] Re: JPA/JDO vs low level API
On Apr 6, 5:23 am, Jeff Schnitzer j...@infohazard.org wrote: The thread-local transaction model that JPA/JDO inherited from EJB assumes the flexibility of RDBMS transactions that let you touch any piece of data you want. That just doesn't work on appengine. Jeff Don't forget that JDO did not inherit the EJB transaction model, per se. JPA does, due to its lineage. There are things in JDO that depend to a certain degree on the ACID properties of transactions, which may break down against GAE/J's BigTable. However, DataNucleus has been happily building plugins for other nonrelational stores. I can't speak for them, but they indicate that there are, thus far, no issues where the semantics of JDO conflict with these other stores (Cassandra, Hadoop, etc). There is an issue entered with JDO, https://issues.apache.org/jira/browse/JDO-651, that is there to address any specification modifications that need to be made to support NoSQL datastores. It appears, though, that BigTable's entity groups may be a different enough beast from the other NoSQL databases that it can't be treated like them. Hard to say. Good or bad, definitely give your feedback on your JDO experiences to DataNucleus and the GAE/J team, particularly Max Ross. The issue tracking systems are at the following locations: https://issues.apache.org/jira/browse/JDO http://code.google.com/p/googleappengine/issues/list Squeaky wheels and all, you know. -matthew -- 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.
[appengine-java] Re: JPA/JDO vs low level API
Thanks you so much for all this responses everybody ! -- 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.
[appengine-java] Re: JPA/JDO vs low level API
I couldn't agree more with Jeff. JDO/JPA on GAE is pants for any real project. I am part of a 4 person development team that recently completed a fairly hefty 6 month GAE project built using GAE, GWT and Guice. We used JDO/Datanucleus for the persistence technology which caused significant problems across the project. As well as the issues that Jeff points out, simple things like IDE integration (predominantly Eclipse) with Datanucleus never seemed to work very well. Getting transaction demarcation to work with how the store 'actually' works is also practically impossible. We burnt a lot of days getting around a mass of silly little issues for no real benefit. To be clear, in standard relational environments we'll use Hibernate (et al) almost exclusively as an ORM, but, in my view, trying to use JDO/JPA on GAE is at this point in time a frivolous exercise that ultimately will heavily limit what you can do on the platform (not discounting the great work done be those that did port the standard over). It also lures you into this familiar relational way of looking at persistence problems which really does not, in any way, translate to how the datastore actually works. I'd be very interested to know how Google's internal projects work with the store -- as presumably, it's going to be a fairly similar interface -- but, if we were starting from scratch, I'd lobby very hard for using the low-level API on its lonesome (it's already a pretty clean service). On Apr 5, 6:22 pm, SkYlEsS shou...@gmail.com wrote: Thanks you so much for all this responses everybody ! -- 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.
[appengine-java] Re: JPA/JDO vs low level API
I've been using Java AppEngine since it became available. I chose JDO for portability and so I could get started very quickly. I can say that JDO offers very little real portability for significant apps because of the very different semantics of the underlying datastore. If I were developing for an SQL datastore, my datamodel would be pretty different. For instance, it is easy in most SQL datastores to use one or more fields as a unique, mutable secondary key (like an email address or Social Security Number). In the appengine datastore, if you have the datastore generate unique primary keys, but you want to enforce a unique mutable secondary key, you need to use a separate entity to serve as the secondary key mutex. This is a fine solution if you are using the low level API, because you can have your data access layer create and check this mutex so this does not bubble up to your application code. However, with JDO, you have to create another pojo and manage it so it can serve as the mutex. Ick. When I chose JDO, no wrapper for the low level existed and documentation of the low level was not great. JDO was well documented so I could get going fast. However, there are now several good alternative frameworks for using the low level datastore. If I were to start today, I would choose one of them and avoid JDO. Now that I know what I know, I will probably write my own low level wrapper so I have more flexibility and control. On Apr 2, 8:46 am, Jeff Schnitzer j...@infohazard.org wrote: An incomplete list of things that are difficult or impossible with JDO/JPA, but easy with Objectify/LowLevelAPI: * Partial indexes * Running multiple concurrent transactions, or (more likely) a transaction + a nontransaction. Because of GAE's transaction model, this is actually necessary quite often. * Migrating your schema. JDO/JPA is particularly brittle, you can't even add primitive fields to a class. * Serializing your entities. With JDO you must detach them explicitly, with JPA (as implemented by DataNucleus) you simply can't. In practice, the biggest difference after abandoning JDO/JPA is that you will stop screaming loudly at your computer, annoying your coworkers. Jeff (copied from the response to the same question on the objectify mailing list) On Fri, Apr 1, 2011 at 4:50 AM, SkYlEsS shou...@gmail.com wrote: I have a question : What are the differences between JPA/JDO and low level API (and Objectify) in practice ? I read everywhere the low level API provides more flexibility, but there are never samples code or evidences to demonstrate it. So I'm wondering in which cases exactly, the low level API is useful ? Thanks in advance -- 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 athttp://groups.google.com/group/google-appengine-java?hl=en. -- 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.
[appengine-java] Re: JPA/JDO vs low level API
The low level works with lists of properties key=value and JDO or JPA sticks those properties into defined (class)objects. Its easier to work with objects than a group of properties. Brandon Donnelson http://gwt-examples.googlecode.com -- 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.
[appengine-java] Re: JPA/JDO vs low level API
Hi, You should also consider 3rd party packages like Objectify who works at an intermediate level of abstraction. The low-level api forces you to handle everything by yourself: the Entity, its Properties, etc... In JPA, JDO: you work much higher in abstraction: you define a Java class as an Entity and then its properties become DS properties as you annotate them. As said: the big difference is abstraction level and resulting guidance for JDO or flexibility for low-level: with low-level, you can do much more things but you have to program much more carefully and now what you do. With JDO/JPA, you get more comfort as you are guided by the pojo structure. Also, JDO/JPA aligns you with Java (inheritance, compiler checks for types, etc...). I would really advise to start somewhere in the middle with a 3rd party package as they are recommended now by Google more than JDO/JPA and learn by using it at its own middle abstraction layer. When you understand better, you will see if you really want / need to go up or down in abstraction or stay where you are. regards didier On Apr 1, 1:50 pm, SkYlEsS shou...@gmail.com wrote: I have a question : What are the differences between JPA/JDO and low level API (and Objectify) in practice ? I read everywhere the low level API provides more flexibility, but there are never samples code or evidences to demonstrate it. So I'm wondering in which cases exactly, the low level API is useful ? Thanks in advance -- 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.
