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 up >> >> In 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 the >> problem. > > 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 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.
I would like to clarify IBM's preference a bit more. At the moment, given the flexibility to have multiple back-ends, we were able to build an iBatis implementation. We are quite happy with iBatis because of its lightweight features and ability for us to optimize our queries. We support iBatis because you can optimize the SQL queries to reduce unnecessary round-tripping and its lightweight object mapping code. But there's a problem, support for the many DBs we currently support in Roller might be a bit tedious and require extensive testing. Therefore, I expressed to Dave that we would like to test his straight JPA back-end implementation and compare it. If it's fast enough (not necessarily faster than iBatis) we are willing to consider it and drop our iBatis support. -Elias > > 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 >
