Hi guys,

some lines on this JPA / Zest from me.

The requirement to be able to use JPA on Zest has from my perspective three
reasons:

1) Standardized, aka "JPA-way" to persist and query Entities (persistent
Objects with Identities)
2) Be able to use a (relational-) schema that has been externally modeled
and "materialized" in the repository, e.g. kind of ER-Model
3) Accessibility by other applications

The reason for 1) is pretty straightforward - there are potentially
millions of developers that knows what JPA is and how to use it. When you
have a project X and the target platform is for what ever reasons Java and
you have to store & query application related states - then you are looking
for JPA support. That simple. On a long term, you are adding lot of
complexity and issues using the nowadays popular Titanic-Class ORM mappers,
but this "secrets" are mostly unknown by the decision-makers.

>From my own experience I know how hard it is to convince developers to use
the "Zest" way of Domain Modeling and it takes months of hard work before
the brain switches over to the Zest way. This is for large projects a
serious issue and a huge risk that just few managers will take !

The second reason is a bit more versatile. The last 20-30 years was the
"relational era". The relational model was derived from the relational
algebra and in the beginning people believed that it is impossible to
develop it in software - but then the first relational databases was
introduced..

Now some people believe that we are living in the post relational era,
where things are "schema-less" and therefore the NoSQL repositories are
buzzing.. Then we have the CAP Theorem that indicates the limits of the
"classical" repositores.. (but that has nothing to do directly with
SQL/NoSQL repositories..)

I personally believe that this schema-less argumentation is a just
non-sense.  There is always a schema. Either there is a single and unique
place, a kind of "horizon of truth", like that what can be found in the
typical ER-Models or the model is distributed across a number of places,
like the application code or even in the developers brain (where is
gradually evaporates). There is always a schema.

The third point is that one wants sometimes to access (and in some case
mutate) the models (and also the states) using 3th party tools. The reason
can be e.g. to evolve the Domain Model using some Modelling Tools or even
doing things like fixing issues directly in the repository - means changing
data. The current approach in Zest where simply the serialized Objects as
JSONs are stored in the repository is simply hard to be used by 3th party
tools. I played with the JSON build-in type in Postgresql where then it is
possible to CRUD using SQL the Zest Entities, but this is everything else
then straightforward.

If I had some free wishes on Zest, I would argue in this directions :

i) Support external schema development, at least for the relational (SQL)
repositories
ii) Keep the ES / EI segregation as this is the coolest thing since sliced
bread; optional support SQL based indexes.
iii) Find a nice way to map Zest entities to the external schema; keep it
simple, do not build a ORM Titanic
iv) JPA is at least for me not required, plain old (and direct) SQL is fine

With i) it would be possible to use Zest even on existing applications
where the schema already exists and can not be changed. ii) is clear - the
external index is just crazy cool. Optionally it would be nice to use a SQL
Index, when one does not want to use ElasticSearch for Indexing iii)
requires some nice/simply way how to model entities in Zest and map them to
the external schema. iv) well, JPA is from my perceptive not a must. Plain
old SQL is just fine. e.g. a tool like http://www.jooq.org/ can be used to
generated the required SQL statements ?

Cheers,
Jiri





2016-09-05 3:49 GMT+02:00 Niclas Hedhman <hedh...@gmail.com>:

> I am doing the Pet Clinic migration to Zest, partly to show how horrid the
> HOA stuff is in comparison. In real world project, the situation is often
> much worse as entities and data transfer classes are separate (not the case
> in Pet Clinic)
>
> So, perhaps the answer is simply a migration strategy and a great vision
> that reduces "clutter".
>
> Cheers
> Niclas
>
> On Sep 5, 2016 08:02, "Paul Merlin" <paulmer...@apache.org> wrote:
>
> > Kent Sølvsten wrote:
> >
> >> This is a tough, but interesting question ......
> >>
> >> [SNIP]
> >>
> >> A few ideas:
> >>
> >> (1)
> >> If the persistence engines in the entitystores are XA capable (such as
> >> for JDBC/NEO4J entitystores) it should not be too difficult.
> >> The basic idea would be to inject a DataSource provided by the appserver
> >> into the EntityStore and let the EntityStore avoid committing - leaning
> >> on commit of the global XA transaction
> >> - and postpone notifying indexers until the global transaction is
> >> committed (we should be able to listen to "commit events").
> >>
> >
> > I did just that with the SQL ES a few years ago.
> > I provided the SQL ES with a Connection that would delegate to a XA
> > Connection and avoid committing, letting the responsibility to commit to
> > the application server.
> > It's working in production since then. But it's nasty and I've been
> lucky,
> > especially because of the presence of an Indexer in that application ....
> >
> > One simple way to look at JPA integration would be to simply use Zest
> > without using its persistence related features.
> > i.e. "if you use JPA, you don't need (cough!) Zest persistance"
> >
> > For this we could do various things to ease users pain:
> > - show (sample, doc, whatever) how one can use composites for e.g. only
> > their service layer while running in some horrid application server and
> > persisting with JPA
> > - have a Value <-> POJO converter, to move state from one world to the
> > other if you really want to
> >
> > IOW, I'm note sure about the value of some JPA/UoW integration.
> >
> > My 0.2 cents
> >
> >
>

Reply via email to