On Feb 21, 2007, at 8:35 AM, Dave wrote:
On 2/20/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:Dave wrote: > Here's some status of the work in the roller_4.0 branch: > a) Datamapper / JPA backend has been promoted > - It's been moved from sandbox and into main source directories > > b) Datamapper / JPA passing all but one test and UI is working> - And I'll be working to keep it in-sync with the Hibernate implementation> - Open issue: JPA wants weblogcategory.websiteid to be nullable > - Open issue: some parameterized queries should be cleaned upIn general, my feeling about the new Datamapper/JPA backend is that it's more confusing and difficult to understand and work on than the current Hibernate backend. Parameterized queries are definitely one part of theproblem.After a couple of off-list discussions with Allen and Elias, I've decided to develop a straight-to-JPA back-end implementation. I hope to have code in place by early next week and passing all tests by late next week. Both Allen and Elias feel that the datamapper is an unnecessary layer. It's purpose is to allow multiple persistence implementations
Its purpose is also to separate application-specific concerns from persistence concerns. The separation of the application into XXXManager was the first step in removing persistence from the responsibility of users, and Datamapper is the final step. Datamapper assumes that you have decided on a using Domain Object Model mapped to persistence and puts all the API-specific stuff into its own little box.
but 1) consensus seems to be that we will only-ever need one persistence layer implementation and 2) JPA itself is a persistence layer abstraction that allows multiple implementations.
Just because Hibernate, Toplink, and OpenJPA implement the same API, it doesn't follow that all code that you write to the JPA API is portable. So before concluding that this marketing statement is true, we should really do due diligence. Just as we found that Hibernate- specific items were used in the object model, we will find Toplink- specific items in the usage of JPA. "Non-standard feature" is the technical term for it. While we endeavored to avoid such usage in the JPA implementation, the JPA spec is not tight enough to avoid accidental usage of product-specific features.
The Datamapper architecture provides for the possibility of implementing behavior specific to an implementation where it is just impossible to be specification-portable.
Craig
I did not oppose the datamapper because I think it's fairly thin layer that gives us additional flexibility, but I can't really argue against those points above. Fortunately, Craig and Mitesh have done all of the hard work. That's why I believe I can do this work so quickly -- plus, I've rewritten Roller's back-end a couple of times before. I will leave the existing datamapper/JPA implementation in place and I'll continue to maintain it for the time being -- it's still a contender. Hopefully, in the very near future we can compare code quality and performance characteristics of JPA vs. Datamapper/JPA vs. iBatis implementations. - Dave
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
