Thanks Jay, Philip, for these advices.
They are certainly valid options for several use cases, and may
indeed be best as initial implementation paths.
But, probably related to my background, I would also like/need to
have a path available for storage in traditional relational
databases.
Especially when I compare this to the way we've integrated
Passerelle (our Triquetrum predecessor) in a clustered server
runtime, including all kinds of team-oriented features and
operational support features.
Old-fashioned databases are still the common approach in many
environments we encounter.
Contrary to your experience, Jay, our general feeling is positive
with JPA and our currently used eclipselink (which is pre-Luna) as a
general "work-horse".
We are currently able to combine many reusable modules and
persistence needs. Some are using plain CRUD-like approaches, others
have a high-throughput workflow engine etc.
We have quite deep in-house knowledge (not myself ;-) ) on how to
apply&tweak things to get the described/required modularity with
that version, which is of course already quite old...
When looking at upgrading to Mars now (and the related equinox,
eclipselink, ...) to try to reimplement this on Triquetrum (and also
on our other OSGi-based projects and frameworks), we seem to hit the
described issues.
regards
erwin
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
Op 04/02/2016 om 13:32 schreef 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
|
