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/01/11 18:22:50 UTC
Heads up: JPA integration and eliminating PersistentObject
I'm working with Craig and Mitesh this week, helping to get their JPA
implementation up and running. I'm running into some issues:
1 - The JPA implementation doesn't include the new Planet interface
2 - The Planet POJOs no longer extent PersistentObject
3 - The Roller POJOs still do
Working on code for #1 I've found that #3 makes things a little
painful. So in my workspace now, I'm working on eliminating the
PersistentObject class entirely and replaced the kludgey store() and
remove() code in HibernatePersistenceStrategy with nice clean
implementations (like the one in Planet's strategy).
Any objections to eliminating PersistentObject?
Any other ideas or suggestions?
- Dave
Re: Heads up: JPA integration and eliminating PersistentObject
Posted by Allen Gilliland <al...@sun.com>.
+1, I've been wanting to remove PersistentObject for quite a while.
I'm not sure exactly how #1 affects #3 since Planet and Weblogger now of
isolated backends, but you are correct that the Planet app needs its own
JDO/JPA backend impl now.
The other good thing about this is that it will require some better
implementations of equals() for various pojos, which is something that I
think we've needed for a while.
-- Allen
Dave wrote:
> I'm working with Craig and Mitesh this week, helping to get their JPA
> implementation up and running. I'm running into some issues:
>
> 1 - The JPA implementation doesn't include the new Planet interface
> 2 - The Planet POJOs no longer extent PersistentObject
> 3 - The Roller POJOs still do
>
> Working on code for #1 I've found that #3 makes things a little
> painful. So in my workspace now, I'm working on eliminating the
> PersistentObject class entirely and replaced the kludgey store() and
> remove() code in HibernatePersistenceStrategy with nice clean
> implementations (like the one in Planet's strategy).
>
> Any objections to eliminating PersistentObject?
> Any other ideas or suggestions?
>
> - Dave
Re: Heads up: JPA integration and eliminating PersistentObject
Posted by Dave <sn...@gmail.com>.
I just committed this work and now I'm working on the
sandbox/jdobackend code to get it working without PersistentObject. I
hope to have something to commit today.
- Dave
Re: Heads up: JPA integration and eliminating PersistentObject
Posted by Allen Gilliland <al...@sun.com>.
Craig L Russell wrote:
> We should start with a high level design for the web interaction. There
> are basically two strategies: entity manager per request and entity
> manager per session.
>
> Entity manager per request: A new EM is obtained for each request.
> Entities that are retrieved from the database are detached at the end of
> the request. These entities are used to send data to the user, and the
> data comes back later in a subsequent request. The backing beans are
> merged into the new entity manager for the request. Changes from the web
> request are applied to the entities and are committed to the back end.
> The big challenge with this approach is the requirement to merge the
> entities at the beginning of each web request.
This is what we do now and I don't see any reason to change it.
>
> Entity manager per session: A new EM is obtained for the session.
> Entities that are retrieved from the database are kept associated with
> the EM at the end of the request. These entities are used to send data
> to the user, and the data comes back later in a subsequent request. The
> backing beans are still associated with the EM when the next request
> comes. Changes from the web request are applied to the entities and are
> committed to the back end. The big challenge with this approach is the
> serialization requirement of the EM, which is currently not specified by
> JSR 220. We would need to find an implementation of the spec that
> supports serialization of the EM and adhere to its (non-standard) behavior.
We don't need to maintain object attachment though multiple requests, so
lets just not even go down that path.
-- Allen
>
> Craig
>
> On Jan 11, 2007, at 1:46 PM, Allen Gilliland wrote:
>
>>
>>
>> Dave wrote:
>>> On 1/11/07, Mitesh Meswani <Mi...@sun.com> wrote:
>>>> It might not be easy to entirely get rid of PersistentObject because of
>>>> the way rest of the roller code is written. The code calls
>>>> strategy.store() on both new and managed object. I went down the
>>>> path to
>>>> remove reference to PersistentObject while implementing
>>>> JPAPersistenceStrategy but had to revert back. See comments in
>>>> JPAPersistenceStrategy#store for more information.
>>> Yes, it will require a fair amount of code changes but I think it's
>>> the right thing to do and I've got time to tackle it now so I'm going
>>> to take shot.
>>
>> I haven't looked at it very carefully, but I would think that the main
>> culprits are the struts actions which often create a new pojo and load
>> it with data from the submitted form (including id) rather than
>> querying for an object and then mutating it's properties. It'll be a
>> fair amount of work to tidy that up, but it's important.
>>
>> -- Allen
>>
>>
>>> - Dave
>>>>
>>>> -Mitesh
>>>>
>>>> Dave wrote:
>>>> > I'm working with Craig and Mitesh this week, helping to get their JPA
>>>> > implementation up and running. I'm running into some issues:
>>>> >
>>>> > 1 - The JPA implementation doesn't include the new Planet interface
>>>> > 2 - The Planet POJOs no longer extent PersistentObject
>>>> > 3 - The Roller POJOs still do
>>>> >
>>>> > Working on code for #1 I've found that #3 makes things a little
>>>> > painful. So in my workspace now, I'm working on eliminating the
>>>> > PersistentObject class entirely and replaced the kludgey store() and
>>>> > remove() code in HibernatePersistenceStrategy with nice clean
>>>> > implementations (like the one in Planet's strategy).
>>>> >
>>>> > Any objections to eliminating PersistentObject?
>>>> > Any other ideas or suggestions?
>>>> >
>>>> > - 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: Heads up: JPA integration and eliminating PersistentObject
Posted by Craig L Russell <Cr...@Sun.COM>.
We should start with a high level design for the web interaction.
There are basically two strategies: entity manager per request and
entity manager per session.
Entity manager per request: A new EM is obtained for each request.
Entities that are retrieved from the database are detached at the end
of the request. These entities are used to send data to the user, and
the data comes back later in a subsequent request. The backing beans
are merged into the new entity manager for the request. Changes from
the web request are applied to the entities and are committed to the
back end. The big challenge with this approach is the requirement to
merge the entities at the beginning of each web request.
Entity manager per session: A new EM is obtained for the session.
Entities that are retrieved from the database are kept associated
with the EM at the end of the request. These entities are used to
send data to the user, and the data comes back later in a subsequent
request. The backing beans are still associated with the EM when the
next request comes. Changes from the web request are applied to the
entities and are committed to the back end. The big challenge with
this approach is the serialization requirement of the EM, which is
currently not specified by JSR 220. We would need to find an
implementation of the spec that supports serialization of the EM and
adhere to its (non-standard) behavior.
Craig
On Jan 11, 2007, at 1:46 PM, Allen Gilliland wrote:
>
>
> Dave wrote:
>> On 1/11/07, Mitesh Meswani <Mi...@sun.com> wrote:
>>> It might not be easy to entirely get rid of PersistentObject
>>> because of
>>> the way rest of the roller code is written. The code calls
>>> strategy.store() on both new and managed object. I went down the
>>> path to
>>> remove reference to PersistentObject while implementing
>>> JPAPersistenceStrategy but had to revert back. See comments in
>>> JPAPersistenceStrategy#store for more information.
>> Yes, it will require a fair amount of code changes but I think it's
>> the right thing to do and I've got time to tackle it now so I'm going
>> to take shot.
>
> I haven't looked at it very carefully, but I would think that the
> main culprits are the struts actions which often create a new pojo
> and load it with data from the submitted form (including id) rather
> than querying for an object and then mutating it's properties.
> It'll be a fair amount of work to tidy that up, but it's important.
>
> -- Allen
>
>
>> - Dave
>>>
>>> -Mitesh
>>>
>>> Dave wrote:
>>> > I'm working with Craig and Mitesh this week, helping to get
>>> their JPA
>>> > implementation up and running. I'm running into some issues:
>>> >
>>> > 1 - The JPA implementation doesn't include the new Planet
>>> interface
>>> > 2 - The Planet POJOs no longer extent PersistentObject
>>> > 3 - The Roller POJOs still do
>>> >
>>> > Working on code for #1 I've found that #3 makes things a little
>>> > painful. So in my workspace now, I'm working on eliminating the
>>> > PersistentObject class entirely and replaced the kludgey store
>>> () and
>>> > remove() code in HibernatePersistenceStrategy with nice clean
>>> > implementations (like the one in Planet's strategy).
>>> >
>>> > Any objections to eliminating PersistentObject?
>>> > Any other ideas or suggestions?
>>> >
>>> > - 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: Heads up: JPA integration and eliminating PersistentObject
Posted by Allen Gilliland <al...@sun.com>.
Dave wrote:
> On 1/11/07, Mitesh Meswani <Mi...@sun.com> wrote:
>> It might not be easy to entirely get rid of PersistentObject because of
>> the way rest of the roller code is written. The code calls
>> strategy.store() on both new and managed object. I went down the path to
>> remove reference to PersistentObject while implementing
>> JPAPersistenceStrategy but had to revert back. See comments in
>> JPAPersistenceStrategy#store for more information.
>
> Yes, it will require a fair amount of code changes but I think it's
> the right thing to do and I've got time to tackle it now so I'm going
> to take shot.
I haven't looked at it very carefully, but I would think that the main
culprits are the struts actions which often create a new pojo and load
it with data from the submitted form (including id) rather than querying
for an object and then mutating it's properties. It'll be a fair amount
of work to tidy that up, but it's important.
-- Allen
>
> - Dave
>
>
>>
>> -Mitesh
>>
>> Dave wrote:
>> > I'm working with Craig and Mitesh this week, helping to get their JPA
>> > implementation up and running. I'm running into some issues:
>> >
>> > 1 - The JPA implementation doesn't include the new Planet interface
>> > 2 - The Planet POJOs no longer extent PersistentObject
>> > 3 - The Roller POJOs still do
>> >
>> > Working on code for #1 I've found that #3 makes things a little
>> > painful. So in my workspace now, I'm working on eliminating the
>> > PersistentObject class entirely and replaced the kludgey store() and
>> > remove() code in HibernatePersistenceStrategy with nice clean
>> > implementations (like the one in Planet's strategy).
>> >
>> > Any objections to eliminating PersistentObject?
>> > Any other ideas or suggestions?
>> >
>> > - Dave
>>
Re: Heads up: JPA integration and eliminating PersistentObject
Posted by Dave <sn...@gmail.com>.
On 1/11/07, Mitesh Meswani <Mi...@sun.com> wrote:
> It might not be easy to entirely get rid of PersistentObject because of
> the way rest of the roller code is written. The code calls
> strategy.store() on both new and managed object. I went down the path to
> remove reference to PersistentObject while implementing
> JPAPersistenceStrategy but had to revert back. See comments in
> JPAPersistenceStrategy#store for more information.
Yes, it will require a fair amount of code changes but I think it's
the right thing to do and I've got time to tackle it now so I'm going
to take shot.
- Dave
>
> -Mitesh
>
> Dave wrote:
> > I'm working with Craig and Mitesh this week, helping to get their JPA
> > implementation up and running. I'm running into some issues:
> >
> > 1 - The JPA implementation doesn't include the new Planet interface
> > 2 - The Planet POJOs no longer extent PersistentObject
> > 3 - The Roller POJOs still do
> >
> > Working on code for #1 I've found that #3 makes things a little
> > painful. So in my workspace now, I'm working on eliminating the
> > PersistentObject class entirely and replaced the kludgey store() and
> > remove() code in HibernatePersistenceStrategy with nice clean
> > implementations (like the one in Planet's strategy).
> >
> > Any objections to eliminating PersistentObject?
> > Any other ideas or suggestions?
> >
> > - Dave
>
Re: Heads up: JPA integration and eliminating PersistentObject
Posted by Mitesh Meswani <Mi...@Sun.COM>.
Hi Dave,
It might not be easy to entirely get rid of PersistentObject because of
the way rest of the roller code is written. The code calls
strategy.store() on both new and managed object. I went down the path to
remove reference to PersistentObject while implementing
JPAPersistenceStrategy but had to revert back. See comments in
JPAPersistenceStrategy#store for more information.
-Mitesh
Dave wrote:
> I'm working with Craig and Mitesh this week, helping to get their JPA
> implementation up and running. I'm running into some issues:
>
> 1 - The JPA implementation doesn't include the new Planet interface
> 2 - The Planet POJOs no longer extent PersistentObject
> 3 - The Roller POJOs still do
>
> Working on code for #1 I've found that #3 makes things a little
> painful. So in my workspace now, I'm working on eliminating the
> PersistentObject class entirely and replaced the kludgey store() and
> remove() code in HibernatePersistenceStrategy with nice clean
> implementations (like the one in Planet's strategy).
>
> Any objections to eliminating PersistentObject?
> Any other ideas or suggestions?
>
> - Dave