You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Yawn, Mike" <my...@ebay.com> on 2009/07/27 17:45:48 UTC
Curious about subclassing rather than entity enhancement
I'm curious about something I read on the 'Entity Enhancement' page.
Currently, our "JPA-like" implementation of annotations uses the
standard JPA annotations, but on an interface rather than a class.
Then, our code generation generates the implementation classes from the
interface; we don't ever add or modify code behind the user's back, so
all the implementation code is fully visible.
On the entity enhancement page, there is a statement that "Some JPA
providers auto-generate new subclasses or proxy objects that front the
user's Entity objects at runtime" ...., and I'm curious how this works
given that it seems that the mechanism for creating an entity object is
to call "new" on it. So, if there is a JPA-annotated class that
represents the entity, and then a JPA implementer creates a subclass of
this to provide loaded / dirty tracking, etc., it seems that any
instantiation of the Entity via "new" would be getting the annotated
base class, not the subclass with the implementation of these features.
How is that being handled in JPA implementations that use subclasses
rather than byte-code weaving ?
Thanks,
Mike Yawn
eBay Inc.
Re: Curious about subclassing rather than entity enhancement
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Mike,
On Jul 27, 2009, at 12:07 PM, Yawn, Mike wrote:
> Hi Craig,
>
> Thanks for the details ... see below
>
>> -----Original Message-----
>> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
>> Sent: Monday, July 27, 2009 10:06 AM
>> To: dev@openjpa.apache.org
>> Subject: Re: Curious about subclassing rather than entity enhancement
>>
>> Hi Mike,
>>
>> On Jul 27, 2009, at 8:45 AM, Yawn, Mike wrote:
>>
>>>
>>>
>>> I'm curious about something I read on the 'Entity Enhancement' page.
>>> Currently, our "JPA-like" implementation of annotations uses the
>>> standard JPA annotations, but on an interface rather than a class.
>>
>> This is a very common (good) pattern for persistence.
>
> [Yawn, Mike] But one that seems to be expressly prohibited by JPA spec
> (Section 2.1, "The entity class must be a top-level class. An enum or
> interface must not be designated as an entity.". Does OpenJPA allow
> this?
Yes. See 5.3 of the OpenJPA manual "Managed Interfaces".
> (If not currently, and we made modifications to work with
> interfaces, would OpenJPA be interested in this code or should we plan
> to keep it in our own branch?)
>
>>
>>> Then, our code generation generates the implementation classes from
>>> the
>>> interface; we don't ever add or modify code behind the user's back,
> so
>>> all the implementation code is fully visible.
>>
>> So you need a factory to allow the user to create a new instance of
>> the implementation class. How do you tell the user what to "new", or
>> perhaps you have a factory with a method like <T> T
>> newInstance(Class<T> interface)?
>
> [Yawn, Mike] We have a DAO class that provides basic lifecycle
> functionality (insert, update, delete, findByPK, plus user-added
> queries). The DAO also provides a createLocal() method that returns a
> non-persistent (local) data object that can later be passed to the
> 'insert' method. The return type of createLocal is the entity
> interface, and what we return is the implementation class with all of
> the state tracking, etc. So our EntityManager methods would mostly be
> calling the DAO.
>
>>> On the entity enhancement page, there is a statement that "Some JPA
>>> providers auto-generate new subclasses or proxy objects that front
>>> the
>>> user's Entity objects at runtime" ...., and I'm curious how this
>>> works
>>> given that it seems that the mechanism for creating an entity object
>>> is to call "new" on it.
>>
>> This is how users create an entity to persist. But once it's
>> persisted, the provider has its own factory that it uses when
>> fetching
>> instances from the database.
>
> [Yawn, Mike] persist doesn't return an object to the caller -- once an
> object is initially persisted, can the user continue to work with that
> object (modify fields), or do they need to retrieve the object from
> the
> EntityManager first? Because in the first case I don't see how the
> implementation can be detecting any state changes to the object.
There are some corner cases if you persist an entity, flush it to the
database, and then continue to modify it. But if you persist and
commit, these issues go away. After commit, the instance is detached
and you need to reacquire the persistent instance from the entity
manager.
Craig
>
>>> So, if there is a JPA-annotated class that
>>> represents the entity, and then a JPA implementer creates a subclass
>>> of
>>> this to provide loaded / dirty tracking, etc., it seems that any
>>> instantiation of the Entity via "new" would be getting the
>>> annotated
>>> base class, not the subclass with the implementation of these
>>> features.
>>
>> Right.
>>
>>> How is that being handled in JPA implementations that use subclasses
>>> rather than byte-code weaving ?
>>
>> Byte-code enhancement is done primarily to allow detection of
>> changes,
>> which by definition isn't needed for new instances (all fields are
>> considered changed for newly persisted instances).
>>
>> Craig
>>>
>>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Mike Yawn
>>>
>>> eBay Inc.
>>>
>>
>> Craig L Russell
>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>
> [Yawn, Mike] Hmm, that P.S. looks anagram-y but I can't decipher it.
>
> Mike
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
RE: Curious about subclassing rather than entity enhancement
Posted by "Yawn, Mike" <my...@ebay.com>.
Hi Craig,
Thanks for the details ... see below
> -----Original Message-----
> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
> Sent: Monday, July 27, 2009 10:06 AM
> To: dev@openjpa.apache.org
> Subject: Re: Curious about subclassing rather than entity enhancement
>
> Hi Mike,
>
> On Jul 27, 2009, at 8:45 AM, Yawn, Mike wrote:
>
> >
> >
> > I'm curious about something I read on the 'Entity Enhancement' page.
> > Currently, our "JPA-like" implementation of annotations uses the
> > standard JPA annotations, but on an interface rather than a class.
>
> This is a very common (good) pattern for persistence.
[Yawn, Mike] But one that seems to be expressly prohibited by JPA spec
(Section 2.1, "The entity class must be a top-level class. An enum or
interface must not be designated as an entity.". Does OpenJPA allow
this? (If not currently, and we made modifications to work with
interfaces, would OpenJPA be interested in this code or should we plan
to keep it in our own branch?)
>
> > Then, our code generation generates the implementation classes from
> > the
> > interface; we don't ever add or modify code behind the user's back,
so
> > all the implementation code is fully visible.
>
> So you need a factory to allow the user to create a new instance of
> the implementation class. How do you tell the user what to "new", or
> perhaps you have a factory with a method like <T> T
> newInstance(Class<T> interface)?
[Yawn, Mike] We have a DAO class that provides basic lifecycle
functionality (insert, update, delete, findByPK, plus user-added
queries). The DAO also provides a createLocal() method that returns a
non-persistent (local) data object that can later be passed to the
'insert' method. The return type of createLocal is the entity
interface, and what we return is the implementation class with all of
the state tracking, etc. So our EntityManager methods would mostly be
calling the DAO.
> > On the entity enhancement page, there is a statement that "Some JPA
> > providers auto-generate new subclasses or proxy objects that front
the
> > user's Entity objects at runtime" ...., and I'm curious how this
works
> > given that it seems that the mechanism for creating an entity object
> > is
> > to call "new" on it.
>
> This is how users create an entity to persist. But once it's
> persisted, the provider has its own factory that it uses when fetching
> instances from the database.
[Yawn, Mike] persist doesn't return an object to the caller -- once an
object is initially persisted, can the user continue to work with that
object (modify fields), or do they need to retrieve the object from the
EntityManager first? Because in the first case I don't see how the
implementation can be detecting any state changes to the object.
> > So, if there is a JPA-annotated class that
> > represents the entity, and then a JPA implementer creates a subclass
> > of
> > this to provide loaded / dirty tracking, etc., it seems that any
> > instantiation of the Entity via "new" would be getting the
annotated
> > base class, not the subclass with the implementation of these
> > features.
>
> Right.
>
> > How is that being handled in JPA implementations that use subclasses
> > rather than byte-code weaving ?
>
> Byte-code enhancement is done primarily to allow detection of changes,
> which by definition isn't needed for new instances (all fields are
> considered changed for newly persisted instances).
>
> Craig
> >
> >
> >
> >
> >
> > Thanks,
> >
> > Mike Yawn
> >
> > eBay Inc.
> >
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
[Yawn, Mike] Hmm, that P.S. looks anagram-y but I can't decipher it.
Mike
Re: Curious about subclassing rather than entity enhancement
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Mike,
On Jul 27, 2009, at 8:45 AM, Yawn, Mike wrote:
>
>
> I'm curious about something I read on the 'Entity Enhancement' page.
> Currently, our "JPA-like" implementation of annotations uses the
> standard JPA annotations, but on an interface rather than a class.
This is a very common (good) pattern for persistence.
> Then, our code generation generates the implementation classes from
> the
> interface; we don't ever add or modify code behind the user's back, so
> all the implementation code is fully visible.
So you need a factory to allow the user to create a new instance of
the implementation class. How do you tell the user what to "new", or
perhaps you have a factory with a method like <T> T
newInstance(Class<T> interface)?
>
> On the entity enhancement page, there is a statement that "Some JPA
> providers auto-generate new subclasses or proxy objects that front the
> user's Entity objects at runtime" ...., and I'm curious how this works
> given that it seems that the mechanism for creating an entity object
> is
> to call "new" on it.
This is how users create an entity to persist. But once it's
persisted, the provider has its own factory that it uses when fetching
instances from the database.
> So, if there is a JPA-annotated class that
> represents the entity, and then a JPA implementer creates a subclass
> of
> this to provide loaded / dirty tracking, etc., it seems that any
> instantiation of the Entity via "new" would be getting the annotated
> base class, not the subclass with the implementation of these
> features.
Right.
> How is that being handled in JPA implementations that use subclasses
> rather than byte-code weaving ?
Byte-code enhancement is done primarily to allow detection of changes,
which by definition isn't needed for new instances (all fields are
considered changed for newly persisted instances).
Craig
>
>
>
>
>
> Thanks,
>
> Mike Yawn
>
> eBay Inc.
>
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!