entity manager aggregation?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

entity manager aggregation?

jamiecampbell
I'm trying to get a system working whereby different bundles are able to
register different entities.

The first thing I researched was whether there's a way to add new
persistable entities to an entity manager at runtime.  If that can be
done then, problem solved.  But I can't find a way to do that.

The second thing I tried was to have an entity manager per registering
bundle, and unify all the entity managers under a central persistence
manager which would then determine which entity manager was appropriate
for a given call.  I tried this by way of having each bundle have a
derived persistence service which proxies the usual calls (eg clear(),
contains(Object), etc) but also has a list of class types so that it
knows what it manages.  Then, the manager calls a method
contains(Class<?>) to find the right manager and proxies to it.  This is
fine for stuff like clear() (clear all managers), and contains(Object)
(find the right one), but things snag for calls like createQuery() which
potentially involve objects across managers, such that there IS no
appropriate manager to proxy to.

I read through the aries JPAEntityManager in hopes it would have some
goodies for scenarios like this, but was unable to find anything.

The openjpa documentation explicitly says that entities CAN be added
after startup, but I've been unable to find how one would do such a
thing.  I'm doing enhancement at build-time so, that part isn't a
problem, I just need something like public void
manager.addEntity(class<?>) or public void
manager.entityManagerUnion(EntityManager mergeWithMe).

Am I missing something simple here?

-Jamie
Reply | Threaded
Open this post in threaded view
|

RE: entity manager aggregation?

Timothy Ward-2


Hi Jamie,

I'm a little confused as to your requirements. It sounds as though you are trying to add new Entities (with relationships to existing entities) to an existing EntityManager at runtime. As the JPA service specification requires the managed classes to live in the same bundle as persistence.xml it is unlikely that you will be able to do this within the existing spec, and I'm not sure that "merging" EntityManagers will do anything to help either.

If there are links between the existing and new Entities then these will not be accessible via a new EntityManager unless that EntityManager also manages the instances. At this point there is no way to consistently load the existing entities from a single client. A Foo loaded by EntityManager1 will not be managed by EntityManager2, but would end up getting passed to it, and there are likely to be horrendous conflicts if both EntityManagers attempt to modify those rows in the database.

I would also like to ask why it is necessary for different bundles to contribute different entities? If the entities are all part of the same data model then they should be part of the same bundle. If they aren't part of the same data model then why can't they have there own persistence unit definition?

I am not aware of any methods such as public void addEntity(class) or public void entityManagerUnion(EntityManager mergeWithMe), but there may well be provider specific methods in OpenJPA. These would be accessible via an unwrapped implementation and may give you the function you are looking for.

I'd be very interested to know what your use case is, as I'd like to help support people using the Aries JPA stack where possible.

Regards,

Tim


----------------------------------------

> Date: Fri, 16 Jul 2010 14:02:29 -0500
> From: [hidden email]
> To: [hidden email]
> Subject: entity manager aggregation?
>
> I'm trying to get a system working whereby different bundles are able to
> register different entities.
>
> The first thing I researched was whether there's a way to add new
> persistable entities to an entity manager at runtime. If that can be
> done then, problem solved. But I can't find a way to do that.
>
> The second thing I tried was to have an entity manager per registering
> bundle, and unify all the entity managers under a central persistence
> manager which would then determine which entity manager was appropriate
> for a given call. I tried this by way of having each bundle have a
> derived persistence service which proxies the usual calls (eg clear(),
> contains(Object), etc) but also has a list of class types so that it
> knows what it manages. Then, the manager calls a method
> contains(Class) to find the right manager and proxies to it. This is
> fine for stuff like clear() (clear all managers), and contains(Object)
> (find the right one), but things snag for calls like createQuery() which
> potentially involve objects across managers, such that there IS no
> appropriate manager to proxy to.
>
> I read through the aries JPAEntityManager in hopes it would have some
> goodies for scenarios like this, but was unable to find anything.
>
> The openjpa documentation explicitly says that entities CAN be added
> after startup, but I've been unable to find how one would do such a
> thing. I'm doing enhancement at build-time so, that part isn't a
> problem, I just need something like public void
> manager.addEntity(class) or public void
> manager.entityManagerUnion(EntityManager mergeWithMe).
>
> Am I missing something simple here?
>
> -Jamie
     
_________________________________________________________________
http://clk.atdmt.com/UKM/go/195013117/direct/01/
Reply | Threaded
Open this post in threaded view
|

Re: entity manager aggregation?

jamiecampbell
On 10-07-19 07:56 AM, Timothy Ward wrote:
>
> Hi Jamie,
>
> I'm a little confused as to your requirements. It sounds as though you are trying to add new Entities (with relationships to existing entities) to an existing EntityManager at runtime. As the JPA service specification requires the managed classes to live in the same bundle as persistence.xml it is unlikely that you will be able to do this within the existing spec, and I'm not sure that "merging" EntityManagers will do anything to help either.
>    

Well, merging or adding to an existing entity manager at runtime were
two possibilities.. if there's a single entity manager, which isn't
constructed until all the information is available, that would be ok
too.  Over the weekend I discovered that spring has an approach for this
,
http://static.springsource.org/spring/docs/2.5.x/reference/orm.html#orm-jpa-setup 
(section 12.6.1.4) and I spent some time seeing if I could get it
working alongside the aries usage I already have, but it appears it will
take more refactoring than I'd like to take on.

> If there are links between the existing and new Entities then these will not be accessible via a new EntityManager unless that EntityManager also manages the instances. At this point there is no way to consistently load the existing entities from a single client. A Foo loaded by EntityManager1 will not be managed by EntityManager2, but would end up getting passed to it, and there are likely to be horrendous conflicts if both EntityManagers attempt to modify those rows in the database.
>
> I would also like to ask why it is necessary for different bundles to contribute different entities? If the entities are all part of the same data model then they should be part of the same bundle. If they aren't part of the same data model then why can't they have there own persistence unit definition?
>    

Well, the big lure of OSGi for me was its support for dynamic modules,
essentially plugins, to build or extend a system via different bundles.  
The application that I'm attempting to refactor in this manner is
currently riddled with combo boxes for mutually exclusive stuff : items
that can't co-exist and thus, shouldn't have either the logic or the
data in existence if it's not being used.  Pretty much all of the
options, however, rely on a common data core, and need to be able to
interact with it.  If I wanted to drop all ability for data source
selectability (eg client ability to pick between derby or mysql or
postgres, etc), I could just force the application to use one (probably
mysql) and all these entity manager complications would be gone.  I'm
just hoping there's an Aries/JPA approach for it.

> I am not aware of any methods such as public void addEntity(class) or public void entityManagerUnion(EntityManager mergeWithMe), but there may well be provider specific methods in OpenJPA. These would be accessible via an unwrapped implementation and may give you the function you are looking for.
>    

I've peered over the source code in OpenJPA and am not able to find
anything in it, even though the OpenJPA documentation says that one of
its big selling features compared to other ORMs is that it CAN add new
entities at runtime.

-Jamie
Reply | Threaded
Open this post in threaded view
|

Re: entity manager aggregation?

jamiecampbell
In reply to this post by Timothy Ward-2
On 10-07-19 07:56 AM, Timothy Ward wrote:
>
> Hi Jamie,
>
> I'm a little confused as to your requirements. It sounds as though you are trying to add new Entities (with relationships to existing entities) to an existing EntityManager at runtime. As the JPA service specification requires the managed classes to live in the same bundle as persistence.xml it is unlikely that you will be able to do this within the existing spec, and I'm not sure that "merging" EntityManagers will do anything to help either.
>    

I reread the specification and I think you're right.  I'll likely need
to refactor the system to use a non-jpa approach, which is unfortunate.  
I think that OpenJPA is jpa-only so I may need to use hibernate (if it
works in an osgi environment, I didn't have much luck last time I tried
it), or at worst have the system implement the databases it supports by
direct driver aggregation.  I admit that it's a real surprise to me that
jpa doesn't support a modular data approach, since polymorphism and
dynamism is kind of at the root of object-oriented programming, and is
much less useful if the associated data lacks the same dynamism...

-Jamie