Hi everybody, I'm looking for ways to make persistence units more dynamic, and I'm still not happy with what I found out there. I posted some ideas on the Gemini JPA forum [1], but I think this list may be a better place for such a general wondering. So I cross post here (sorry, I should have thought twice before rushing into the Gemini forum).
I hope there are some more experienced people here with advices about the different technics I came up with (still based on Gemini/EclipseLink though, since that's what we are using so far). Also, any comment about implementations of the OSGi JPA spec other than Gemini JPA is welcome. 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 persistence unit 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 thought for a while that EclipseLink's composite persistent units [2] could save me, but it's definitely too static to be used there. == 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 Gemini or any other implementation support this. I tried with Gemini without any luck, and a bug about that [3] seems to leave the question open. An even greater feature would be to add entities at runtime (for example using a white-board pattern to register new entities). But EclipseLink doesn't seem to do that. Again, maybe there is better implementations. Anyway, this approach would probably be tricky to use 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 some problems [4], main one being that the ALTER TABLE statements are not handled by EclipseLink and must be manually generated. Also, resulting tables are likely to be big and messy, and 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 would say 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 consider 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, 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 [1] http://www.eclipse.org/forums/index.php/m/890509/#msg_890509 [2] http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Composite_Persistence_Units [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=356509 [4] http://www.eclipse.org/forums/index.php/m/890024/#msg_890024 _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
