You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Dave <sn...@gmail.com> on 2007/02/20 18:49:36 UTC
Status of work in branches/roller_4.0
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
c) Roller-Weblogger UI updated to work with new Roller-Planet data model
- Roller UI now assumes that there is one default Planet object
- Roller UI now uses Planet PropertiesManager instead of PlanetConfigData
d) components/core Module created
- For code that is shared in both Roller-Planet and Roller-Weblogger
- Right now this is only the core persistence classes
- Like Planet, we build core separately and commit the jar to SVN
- (see tools/roller-core/roller-core.jar and
tools/roller-planet/roller-planet.jar)
e) roller_4.0 branch is in sync with trunk as of today
- And I'll be working to keep it in sync until we're done with 3.x releases
- Beware: createdb and 3xx-to-400 migration scripts are in flux right now
f) Started Struts2 migration, in anticipation of Struts2 UI work in 4.0
- Struts2 jars now included in build
- Struts2 filter now included and mapped
Comments, objections and suggestions are welcome...
Next I plan to work on open issues in (b) and do some JMeter testing
(and possibly some
profiling) to compare the JPA and Hibernate implementations.
- Dave
Re: Status of work in branches/roller_4.0
Posted by Dave <sn...@gmail.com>.
On 2/20/07, Allen Gilliland <al...@sun.com> 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
>
> I refuse to believe this is a JPA thing. it has to be something with
> the way you are using weblogs and categories which is broken because
> it's obvious that the websiteid for a category should never be null. We
> have other associations which are exactly like this (folder, weblog
> entry) which should be broken as well if this was really a JPA issue.
I didn't really mean to imply it is the fault of JPA, but it
definitely an open issue in the current roller_4.0 code base that
needs to be fixed.
> > - 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.
> > c) Roller-Weblogger UI updated to work with new Roller-Planet data model
> > - Roller UI now assumes that there is one default Planet object
> > - Roller UI now uses Planet PropertiesManager instead of PlanetConfigData
>
> This one actually scares me a little bit. I have been operating under
> the assumption that the Planet application can be worked on and progress
> on a different schedule than the Weblogger application and they don't
> need to be tied together.
>
> I think we need to be a little careful about promoting the changes in
> the Planet app to be used by Weblogger until things have stabalized.
I agree that Roller and Planet can be on different release schedules,
but I don't think it's acceptable to be stuck at Roller-Planet 3.1
level in Roller 4.0.
- Dave
Re: Status of work in branches/roller_4.0
Posted by Dave <sn...@gmail.com>.
Some more status...
In the braches/roller_4.0_newbackend branch we now have ToplinkJPA and
OpenJPA working and passing 100% of tests running against both MySQL
and Derby.
In that branch, the tests now default to the new straight-to-JPA
implementation using OpenJPA and Derby. Next, I'll be working on
getting the UI up and running for use and performance testing.
- Dave
Re: Status of work in branches/roller_4.0
Posted by Craig L Russell <Cr...@Sun.COM>.
On Feb 21, 2007, at 8:35 AM, Dave wrote:
> On 2/20/07, Allen Gilliland <al...@sun.com> 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
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Status of work in branches/roller_4.0
Posted by Allen Gilliland <al...@sun.com>.
Dave wrote:
> On 2/20/07, Allen Gilliland <al...@sun.com> 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 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.
That sounds like a good approach to me.
-- Allen
>
> - Dave
Re: Status of work in branches/roller_4.0
Posted by Elias Torres <el...@torrez.us>.
Dave wrote:
> On 2/20/07, Allen Gilliland <al...@sun.com> 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
>
Re: Status of work in branches/roller_4.0
Posted by Dave <sn...@gmail.com>.
On 2/20/07, Allen Gilliland <al...@sun.com> 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 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
Re: Status of work in branches/roller_4.0
Posted by Allen Gilliland <al...@sun.com>.
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
I refuse to believe this is a JPA thing. it has to be something with
the way you are using weblogs and categories which is broken because
it's obvious that the websiteid for a category should never be null. We
have other associations which are exactly like this (folder, weblog
entry) which should be broken as well if this was really a JPA issue.
> - 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.
>
> c) Roller-Weblogger UI updated to work with new Roller-Planet data model
> - Roller UI now assumes that there is one default Planet object
> - Roller UI now uses Planet PropertiesManager instead of PlanetConfigData
This one actually scares me a little bit. I have been operating under
the assumption that the Planet application can be worked on and progress
on a different schedule than the Weblogger application and they don't
need to be tied together.
I think we need to be a little careful about promoting the changes in
the Planet app to be used by Weblogger until things have stabalized.
-- Allen
>
> d) components/core Module created
> - For code that is shared in both Roller-Planet and Roller-Weblogger
> - Right now this is only the core persistence classes
> - Like Planet, we build core separately and commit the jar to SVN
> - (see tools/roller-core/roller-core.jar and
> tools/roller-planet/roller-planet.jar)
>
> e) roller_4.0 branch is in sync with trunk as of today
> - And I'll be working to keep it in sync until we're done with 3.x releases
> - Beware: createdb and 3xx-to-400 migration scripts are in flux right now
>
> f) Started Struts2 migration, in anticipation of Struts2 UI work in 4.0
> - Struts2 jars now included in build
> - Struts2 filter now included and mapped
>
>
> Comments, objections and suggestions are welcome...
>
> Next I plan to work on open issues in (b) and do some JMeter testing
> (and possibly some
> profiling) to compare the JPA and Hibernate implementations.
>
> - Dave