Good thoughts.... I think it is a long path forward, and looking at JPA
"fragility" and I now doubt it is doable. With fragility, I mean how
sensitive JPA applications are to the execution model of JPA itself. Since
we don't follow that, I doubt we can make it work reliably.

In regards to SQL Schema to Zest generation; that is actually a really
persuasive argument. Are there any existing tools that let you work with an
SQL Schema and tell the tool what object model you want out of it?

I agree that there is always a schema, and I don't think that anyone really
disagrees with that. It is more a matter of "rigid" or "flexible" schema.
The "rigid" world requires more process overhead to create and evolve, and
over time end up with 500 columns that are mostly empty.

So, I am somewhat keen to explore the JDBC track further.

Niclas

On Sep 18, 2016 20:04, "Jiri Jetmar" <juergen.jet...@gmail.com> wrote:

> 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