You can also have a look at OrientDB. It's quite nice, cause it can
be easily used in embedded modus:
http://orientdb.com/docs/2.0/orientdb.wiki/Object-Database.html
Moreover, my CQ has been accepted to bring the OrientDB library to
Eclipse Orbit. We just have to resolve some minor issues at the
Orbit Bundle Recipes project.
Best,
Philip
Am 04.02.2016 um 13:32 schrieb Jay Jay
Billings:
The first implementation of ICE's
IPersistenceProvider service was JPA based and we used
EclipseLink.
In my opinion, it was the worst way we could do
persistence. Maybe we used it wrong, but it was slow,
cumbersome, constantly breaking and we were genuinely lucky to
get it both working and get the rest of ICE running in an OSGi
environment. Almost nothing about it worked as written and most
of the time the target platform wouldn't even resolve it
correctly in development. That was about three years ago, so
maybe it is all fixed now.
It was so bad in the end that I deleted it completely
and took a week to reimplement our IPersistenceProvider service
in XML using JAXB (and not the JAXB implementation from
EclipseLink!). The result was a really sweet, robust system that
almost never breaks. We've barely touched it in three years and
it was ten times faster for our application. It is a poor man's
database for sure, but we have no complaints.
So, I recommend you think about it long and hard and
do many tests before committing to JPA and EclipseLink.
My apologies to Doug if this comes off as offensive.
I'm sure EclipseLink works for some folks, it just didn't for
us.
Jay
On Feb 4, 2016 5:59 AM, "Mike
Milinkovich" < mike.milinkovich@xxxxxxxxxxx>
wrote:
Adding Doug Clarke (EclipseLink Project Leader) to this,
as he would be the guy who actually knows what's going on.
Doug - What is the state of EclipseLink being available as
an OSGi bundle? (I think you'll have to subscribe to the
list to reply)
On 04/02/2016 2:46 AM, Erwin de Ley wrote:
Dear all,
Triquetrum's goal is to be an open and extensible platform
itself, but also to be able to deliver plugins that can
easily be integrated in other such platforms.
And the typical shape will be an RCP application I guess.
(we'll also deliver headless components, but this is even
irrelevant for the issue described)
At some point in the near future, we'll start integrating
a persistence service, preferably based on JPA.
We will need to be able to provide & register entity
implementations from our bundles, while also allowing
other bundles to do the same.
And without blocking the possibility that they should
belong to the same persistence unit.
(e.g. cases where extensions provide entity subclasses
that must fit in one of the normal mapping strategies, or
where there are associations mapped to foreign keys etc)
But there seem to be some issues with the current
state-of-affairs to use a JPA implementation in an
OSGi/RCP setup, in a modular way.
I.e. it is required that there is
one-persistence-bundle-to-rule-them-all that registers all
entities in one shot.
This of course does not fit our needs (as also for many
other modular systems, for which OSGi is meant)
Furthermore it even seems that eclipselink, since some
time, no longer targets an OSGi runtime, and that their
support for this has been moved to Gemini JPA.
But Gemini JPA seems quite dead : a milestone that remains
unfinished since a couple of years.
Does anyone have any experience in this? There are several
old-and-more-recent forum posts and bugzilla tickets open
in this domain, but there seems to be no
evolution/solution in the 2 mentioned eclipse projects. Is
there some effort/stretegy on some eclipse foundation PMC
level or so, to determine what the strategy is related to
JPA/OSGi/eclipse/modularity?
thanks
erwin
_______________________________________________
science-iwg mailing list
science-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/science-iwg
_______________________________________________
science-iwg mailing list
science-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/science-iwg
_______________________________________________
science-iwg mailing list
science-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/science-iwg
--
~~~~~~~~~~~~~~~~~~~~~~~~
OpenChrom - the open source alternative for chromatography / mass spectrometry
Dr. Philip Wenig » Founder » philip.wenig@xxxxxxxxxxxxx » http://www.openchrom.net
~~~~~~~~~~~~~~~~~~~~~~~~
|
