I would like to be able to create persistence bundles which have their
schema created when/if the database is created (or simply when the
tables are missing). OpenJPA has a provider-specific property to
support this, and I believe Hibernate does as well, but I would like to
be able to create bundles which are not tied (at build time, anyway) to
a specific provider. Clearly, when the persistence unit finishes
construction, the bundle becomes tied to a specific provider, and cannot
jump around again during the same session, and that part is fine.
1) The kludgiest way I can come up with to do this is one bundle for
every provider, which would work but has a ton of duplication (aka
99.999%) and would result in quite a lot of bundle proliferation for my
situation (lots of distinct persistence bundles).
2) Next up on the kludgometer is just to stick in all the
provider-specific properties I *might* need (or, that I will need if the
relevant provider is selected), and rely on my understanding of the jpa
specs that unknown properties must be ignored (thus making this approach
safe, at least in situations where providers make good namespace
selections). This avoids bundle proliferation but makes the designer
part of me that likes elegance cringe. It also means that if a new
provider is to be supported, ALL existing persistence bundles,
separately, would need to be build-time extended for whatever properties
might be needed. A bigger problem with this is that with the system I'm
dealing with, third party persistable extensibility is a real
possibility (am I remembering correctly that an Aries JPA environment
has to have just one provider? Otherwise I guess third party stuff
could stick with whatever provider they were already using).
3) Only a bit kludgy would be if the provider-specific functionality is
along the same functional lines, whether some sort of jndi resolvability
might work. It's already demonstrated on the value side, for data
source resolution (eg osgi:service/javax.sql.DataSource with or without
filter, eg in the blog example) so the question would be whether or not
sensible xml could be constructed where even the property name itself is
jndi-resolved (eg <property
name="osgi:service/aStringTypeForBuildSchemaPropertyName"
value="osgi:service/aStringTypeForBuildSchemaPropertyValue">). The
slight kludginess is that you'd still have to have properties that some
providers won't support, so you might still end up with some
persistence.xml noise.
4) Seemingly least kludgy but maybe impossible is some kind of mechanism
for run-time persistence unit property injection, which would leave the
persistence.xml files clean of provider specific stuff until it's pushed
in. I would guess you'd need some sort of way of speedily doing the
update before the persistence definition consumer (which makes the
emf-factory available) gets to it, and I'm not sure how, if possible,
one would do that.
Are there other viable options I haven't considered? For now I'm going
to proceed along the path of #2 , but I'm hoping for better suggestions :)
-Jamie
- persistence.xml : provider-specific extensibility? jamie campbell
-
