On Wed, Sep 24, 2014 at 11:24 AM, Balázs Zsoldos <balazs.zsol...@everit.biz> wrote:
> 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. > You guessed correct :) However I'm glad to see this issue validated by someone else. FYI I'm considering something like the following scheme a) when generating schema-bundles (our DB stuff is 80% generated code) they will be marked as singletons Bundle-SymbolicName: <bsn>;singleton:=true b) they will export a (ideally generated) capability which names their schema and it's version, something like: Provide-Capability: sql.schema;\ sql.schema="${schema.namespace}";\ version:Version="${schema.version}" thus dependent bundles can specifically declare which schema bundle they work with if there is a need (i.e. for instance if they depend on a specific bug fix in the DB schema, this wouldn't be strictly required). I haven't thought of a way to actually block legacy schema bundles from resolving yet. I'd like to do this in pure osgi as opposed to proprietary impl. However, perhaps an agent which listens to wiring events and given a set of requirement namespaces persists those such that on future starts the framework will always block a lower level capability or something like that... such a bundle might be re-usable. thoughts? > > 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 > -- *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
