Home » Eclipse Projects » Gemini » Dynamic persistence units (Any ideas?)
| Dynamic persistence units [message #890509] |
Fri, 22 June 2012 09:10  |
 Thomas Gillet
Messages: 14
Registered: May 2011 |
Junior Member |
|
|
Hi everybody,
I'm looking for ways to make persistence units more dynamic for a while now, and I must say I didn't find anything satisfying. I sincerely hope it's only because I missed the good things.
So meanwhile I post some thoughts here. (Maybe not the best place though, feel free to indicate places more suitable for general topics like this.)
EDIT: cross-posted on the osgi-dev mailing list with the same subject (see mail-archive.com).
Note: I use the word "module" bellow to reference any bundle or group of bundles implementing a given feature.
1. Multiple PUs
That's what we do now. Each module embeds a PU with the entities it needs. Easy. But:
- This leads to a lot of different PUs, sometime with very little data in it (some of them contains only a single entity with only one single field).
- No mapping or query across different PUs. So when several modules need to add properties on the same entity, each PU must handle its own "foreign key" column, stay synchronized when an entity is removed, etc... Also there is no way to query entities using properties from different modules.
I though for a while that EclipseLink's composite persistent units could save me, but the use of static <jar-file> tags in the persistence.xml make this feature unusable in this case.
2. Extending PU at runtime / deployment-time
The simple and obvious approach (well obvious for me at least) is to add a fragment with new entities to a PU bundle.
This would be a great feature and the exclude-unlisted-classes tag seems to be the solution, but it is not clear to me if it is supported or not by Gemini JPA. It's not working for me, and the only bug I found about this is bug #356509 about a missing test case (sorry I cannot post links), which just confused me more.
An even greater feature would be to add entities at runtime (for example using a white-board pattern to register new entities). But I don't see how to do it with EclipseLink (and I didn't check any other implementation for now).
Anyway, this approach would probably cause problems with load-time weaving.
3. Dynamic entities
As a last resort, I gave a shot to the dynamic entities available in EclipseLink.
I managed to create some kind of "dictionary entity", which is basically a map where you can add any property. So there is one entity type for each "important" object in my application, and then every module is free to add the properties it needs. A new column is created for each new property.
This approach could bring a lot of flexibility to my app, resolving the issues about cross-module mapping and query. But I'm still struggling with 2 main issues there:
- The persistence unit must be restarted after adding a property (no way to use properties added after the dynamic entity has been added to the session).
- The ALTER TABLE statement to add the new columns must be generated manually, including the column data definition (found no way to get it from EclipseLink, even though it does generate it at table creation time). Meaning I have an ugly switch to map each java class to the appropriate SQL statement. At this point I'm wondering if I still need to use JPA at all...
Then resulting tables are likely to be big and messy. Also only basic data types are handled. I guess support for collections or even relational mappings is possible but would require a fair amount of code. Unless maybe there is a way to construct a dynamic entity from an existing (annotated) class, so modules could provide entities or embeddables as property values.
4. JDO
Drastic change. But after reading some documentation, I think the JDO API is far more comprehensive than the poor JPA one.
Especially, it seems that support for programmatic persistence unit creation and for dynamic weaving is part of the standard API. Both features I would think essentials for a portable integration into an OSGi environment.
But I didn't try any actual implementation, so maybe it's only a good idea on paper.
If someone could shed some light on JDO dynamic capabilities compared to JPA, I would be eager to read it.
And that's it. End of the long speech.
Hope it could bring pertinent comments about all that. Maybe even solutions, who knows?
-- Thomas
[Updated on: Thu, 28 June 2012 11:49] Report message to a moderator |
|
|
Current Time: Sun May 19 17:14:05 EDT 2013
Powered by FUDForum. Page generated in 0.02274 seconds
|
] 
Search
Help
Register
Login
Home
