I had similar issues and due to this reason, I left JPA and started to use Liquibase + Querydsl. I also developed some opensource modules and components to make it easier to use them together in the way that each bundle has to know only its own versioned schema. You can find more info about it here: http://bzsoldos.wordpress.com/2014/06/18/modularized-persistence/
If you do not have any chance to switch the technology stack (guess it is liferay and hibernate :)), in that case this will not work for you. Regards, Balazs On Wed, Sep 24, 2014 at 5:14 PM, Raymond Auge <raymond.a...@liferay.com> wrote: > Oh man... singleton bundle... wow totally missed that one. Glad I wasn't > writing the osgi cert at that moment. > > So yes this solves part of the model. > > The other part is to preventing a bundle requiring an older version of a > schema from resolving once the schema has been elevated beyond it's version. > > On Wed, Sep 24, 2014 at 11:01 AM, Thomas Watson <tjwat...@us.ibm.com> > wrote: > >> Perhaps I am simplifying the scenario, but isn't this a bundle >> singleton? Here I am assuming the same bundle symbolic name is always >> providing the schema that you want to be a singleton also. >> >> There than bundle singletons, which equate to the osgi.identity >> capability namespace, there is no notion of a capability singleton. >> >> Tom >> >> >> >> >> >> From: Raymond Auge <raymond.a...@liferay.com> >> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> >> Date: 09/24/2014 09:55 AM >> Subject: [osgi-dev] Requirements and Capability uniqueness model? >> Sent by: osgi-dev-boun...@mail.osgi.org >> ------------------------------ >> >> >> >> Is there a provision or mechanism in Req&Cap which might enforce >> uniqueness? >> >> One scenario for this is different versions of bundles requiring >> different DB schema of the same DB tables. >> >> We have modules which build/upgrade their schema on demand when new >> versions are installed.. but this breaks the osgi "mutli bundle version" >> model. >> >> I'm wondering what is the best way to model this. >> >> I'd like to enforce the following model: >> >> 1) when a bundle attached to a schema resolves it sets a capability of >> it's schema to some version (this value is persisted system wide) >> 2) a new bundle version cannot resolve if a lower version bundle attached >> to same schema is still active (i.e. once the old bundle is stopped, and >> the new one is allowed to resolve it bumps up the schema version) >> 3) an old bundle version cannot resolve once the schema version has been >> elevated to some higher level >> >> -- >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> (@rotty3000) >> Senior Software Architect >> *Liferay, Inc.* <http://www.liferay.com/> (@Liferay) >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect > *Liferay, Inc.* <http://www.liferay.com> (@Liferay) > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
