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
