Is there a provision or mechanism in ReqCap 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
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
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
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
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
How do changes to enums affect versioning?
I believe, theoretically, adding values to be binary compatible, and should
therefore constitute a MINOR api change.
Just making sure since this is not mentioned in the semver white paper.
--
*Raymond Augé*
I believe that adding values to an enum is NOT binary compatible, therefore it
would be a major change. Any switch statements written against the old version
will no longer be exhaustive after the addition of the new value. This could
substantially alter the logic of any client code.
Neil
On
