JPA revisited

[Niclas Hedhman <ni...@hedhman.org>]

Gang,
last time I brought up JPA, I think the consensus became; too complex to
bother. But I think the need for "conventional persistence"
interoperability is still an issue for us, and I think it should be tackled.

Spring (and others?) are promoting a Repository-pattern for Spring Data
JPA[1] and perhaps this is an abstraction that is reasonable to adapt to.

We could either expose a relatively simple Repository SPI for an
entitystore.repository to use, which only deals with the exact operations
that the UnitOfWork needs, OR we could call it a entitystore.springdatajpa
and interface directly with Spring Data JPA's API.

The former is much more flexible and allows users to create an arbitrary
repository, such as a Rest server, but will require the user a bunch of
more work. The latter will be very specific to Spring Data JPA, but we can
probably handle the entire setup without much user interaction. The
downside is that people is likely to quickly request more features from
Spring Data to be supported, and it may become a mess in the long run.

Of course, we could also do both.

Any insights, ideas and arguments are most welcome.


[1]
http://docs.spring.io/spring-data/jpa/docs/1.4.1.RELEASE/reference/html/jpa.repositories.html

Cheers
-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: JPA revisited

[Niclas Hedhman <ni...@hedhman.org>]

Just finished studying jOOQ and I think it looks really, really good for
people that work with SQL data (not objects).

It also supports that the code generation tool can be extended, but can we
actually use that to generate anything meaningful at all? Would it make
sense to get Entities with Property methods generated from a schema, where
references must be handled manually? Or could a descriptor be handed to the
generator, pointing out Associations... but that sounds like slippery slope
to ORM.

I think some experimentation is needed to get some more ideas.

Niclas

On Sat, Oct 22, 2016 at 10:28 PM, Paul Merlin <pa...@nosphere.org> wrote:

> s/former/latter
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: JPA revisited

[Paul Merlin <pa...@nosphere.org>]

s/former/latter

Re: JPA revisited

[Paul Merlin <pa...@nosphere.org>]

Niclas Hedhman a �crit :
> Yes, there are many variables and a lot of challenges. Perhaps this is an
> overall bad idea, but I am desperately seeking a workable RDBMS solution
> that is easily "accepted" by the wider community, and ORM is complex, so
> creating our own from scratch may not be feasible (we tried before).
>
> At the simplest level, I imagine that the JPA bean is mapped against an
> Zest EntityComposite, possibly by naming convention. Querying is done with
> "Named Queries", and those basically reside on the JPA side of the story.
> This level would mean that everything is modeled 3 times (SQL, JPA and
> EntityComposites) which is far from ideal.
>
> I doubt that the JPA spec has a dynamic interface, but I know that
> Hibernate does, so although I kind of hate Hibernate and its bugs, it could
> perhaps be possible to hook into that.
>
> And yes, your list of questions are incredibly important and need to be
> addressed in detail.
>
> Are there other choices than JPA, that are making the lives easier? Apache
> Cayenne, Apache empire-db, MyBatis (tried before), jOOQ ?

The mismatch between Zest state modeling and JavaBeans is central. All
theses Java ORMs are tied to JavaBeans.

Our SQL support is a RDBMS solution where all is modeled as Zest entities.
But you have no control to the database schema.
 
If the solution we need to come up with must let users control their DB
schema we may have to think about short-circuiting JPA/JavaBeans.

On the other hand if it must let users write JPA queries, use Spring
Data Repository or JPA Query SQL then we will have to cope with JavaBeans.

I think that the former is a trap, even if we accept to consider e.g.
generating Zest or JPA entities at build time (e.g. using annotation
processors).

Considering other RDBMS solutions than ORMs ; with jOOQ we could provide
some BaseJooqEntityStore or helpersfor users to map Zest state to SQL.
The querying story could be based on jOOQ native queries and a
JooqEntityFinder that populates Zest state from the query results, based
on naming convention or something, maybe user code. jOOQ looks really
easy to extend, see Record.into(..) methods and the RecordMapper type.

So, no JPA magic but it may be quite usable for people that want control
over their SQL schema.

> OR, are we confident to take on ORM in some form or the other? Personally,
> I am not... I am very weak on SQL and don't intend to become a master
> anytime soon.

Heh, me neither.

Re: JPA revisited

[Niclas Hedhman <ni...@hedhman.org>]

Yes, there are many variables and a lot of challenges. Perhaps this is an
overall bad idea, but I am desperately seeking a workable RDBMS solution
that is easily "accepted" by the wider community, and ORM is complex, so
creating our own from scratch may not be feasible (we tried before).

At the simplest level, I imagine that the JPA bean is mapped against an
Zest EntityComposite, possibly by naming convention. Querying is done with
"Named Queries", and those basically reside on the JPA side of the story.
This level would mean that everything is modeled 3 times (SQL, JPA and
EntityComposites) which is far from ideal.

I doubt that the JPA spec has a dynamic interface, but I know that
Hibernate does, so although I kind of hate Hibernate and its bugs, it could
perhaps be possible to hook into that.

And yes, your list of questions are incredibly important and need to be
addressed in detail.

Are there other choices than JPA, that are making the lives easier? Apache
Cayenne, Apache empire-db, MyBatis (tried before), jOOQ ?


OR, are we confident to take on ORM in some form or the other? Personally,
I am not... I am very weak on SQL and don't intend to become a master
anytime soon.


Niclas

On Sat, Oct 22, 2016 at 8:12 PM, Paul Merlin <pa...@nosphere.org> wrote:

> Hey,
>
> Niclas Hedhman a écrit :
> > Gang,
> > last time I brought up JPA, I think the consensus became; too complex to
> > bother. But I think the need for "conventional persistence"
> > interoperability is still an issue for us, and I think it should be
> tackled.
> >
> > Spring (and others?) are promoting a Repository-pattern for Spring Data
> > JPA[1] and perhaps this is an abstraction that is reasonable to adapt to.
> >
> > We could either expose a relatively simple Repository SPI for an
> > entitystore.repository to use, which only deals with the exact operations
> > that the UnitOfWork needs, OR we could call it a
> entitystore.springdatajpa
> > and interface directly with Spring Data JPA's API.
> >
> > The former is much more flexible and allows users to create an arbitrary
> > repository, such as a Rest server, but will require the user a bunch of
> > more work. The latter will be very specific to Spring Data JPA, but we
> can
> > probably handle the entire setup without much user interaction. The
> > downside is that people is likely to quickly request more features from
> > Spring Data to be supported, and it may become a mess in the long run.
> >
> > Of course, we could also do both.
> >
> > Any insights, ideas and arguments are most welcome.
> >
> >
> > [1]
> > http://docs.spring.io/spring-data/jpa/docs/1.4.1.RELEASE/
> reference/html/jpa.repositories.html
> >
> > Cheers
>
> I'll try to add water to the mill.
>
> At first sight and in the spirit of the rest of the SDK I'd say either
> we do none, or, both and plus. But, reading about the so called "JPA
> repositories" they seem to be Spring Data specific, or I missed something.
>
> What we can do today with the Spring library is embed a Spring app into
> a Zest app, or the opposite. Then for example:
>
> @Service UserRepository;
>
> In this model, all "entities" are plain JPA entities, not composites.
> The UnitOfWork is of no use. The data mapping *and querying* is done the
> JPA way.
>
> We could imagine a SpringDataRepositoryConcern that injects some zest
> into the JPA entities on Repository invocations to enhance the integration.
>
> Zest and Spring collaborate without being tied together, persistence is
> handled by Spring only.
>
> I assume that the subject at hand is thatwe want Entity Composites
> coming in and out some Spring Data Repository.
>
> Some questions come to mind, loosely:
>
> Who would instantiate entities objects?
>
> What would the programming model be?
> Are entities declared using interfaces/mixins?
> Annotated with JPA annotations?
>
> Would querying using JPA and Repository "query methods" be supported?
> Would Zest indexing be supported? In addition to JPA querying?
>
> Would users be statisfied with that?
>
> How to map Zest state model to/from JPA entities, Property/Association
> to beans?
>
> In my experience beans based tools are tied to the JavaBean model and
> don't offer extension points to work around it. If Spring Data has
> something like an EntityState we could hook into it.
> Or we could do it the other way around: user declares a JPA entity as a
> bean class with a state interface using the JavaBean convention, plus a
> corresponding state interface using the "Zest convention"
> (Property<?>/*Association<?>), then assemble the corresponding Entity
> Composite with these two interfaces, mixes in the JPA entity impl and we
> provide Property<?> *Association<?> mixins and/or concerns that maps
> to/from the JavaBean convention. Basically binding Zest and JavaBeans
> state.
>
> All this feels a bit blury. I think that the resulting programming model
> is key, if it's a burden people won't use it. If we invest time on this
> to increase adoption we need a clear usage path.
>
> /Paul
>
>
>
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: JPA revisited

[Paul Merlin <pa...@nosphere.org>]

Hey,

Niclas Hedhman a �crit :
> Gang,
> last time I brought up JPA, I think the consensus became; too complex to
> bother. But I think the need for "conventional persistence"
> interoperability is still an issue for us, and I think it should be tackled.
>
> Spring (and others?) are promoting a Repository-pattern for Spring Data
> JPA[1] and perhaps this is an abstraction that is reasonable to adapt to.
>
> We could either expose a relatively simple Repository SPI for an
> entitystore.repository to use, which only deals with the exact operations
> that the UnitOfWork needs, OR we could call it a entitystore.springdatajpa
> and interface directly with Spring Data JPA's API.
>
> The former is much more flexible and allows users to create an arbitrary
> repository, such as a Rest server, but will require the user a bunch of
> more work. The latter will be very specific to Spring Data JPA, but we can
> probably handle the entire setup without much user interaction. The
> downside is that people is likely to quickly request more features from
> Spring Data to be supported, and it may become a mess in the long run.
>
> Of course, we could also do both.
>
> Any insights, ideas and arguments are most welcome.
>
>
> [1]
> http://docs.spring.io/spring-data/jpa/docs/1.4.1.RELEASE/reference/html/jpa.repositories.html
>
> Cheers

I'll try to add water to the mill.

At first sight and in the spirit of the rest of the SDK I'd say either
we do none, or, both and plus. But, reading about the so called "JPA
repositories" they seem to be Spring Data specific, or I missed something.

What we can do today with the Spring library is embed a Spring app into
a Zest app, or the opposite. Then for example:

@Service UserRepository;
 
In this model, all "entities" are plain JPA entities, not composites.
The UnitOfWork is of no use. The data mapping *and querying* is done the
JPA way.

We could imagine a SpringDataRepositoryConcern that injects some zest
into the JPA entities on Repository invocations to enhance the integration.

Zest and Spring collaborate without being tied together, persistence is
handled by Spring only.

I assume that the subject at hand is thatwe want Entity Composites
coming in and out some Spring Data Repository.

Some questions come to mind, loosely:

Who would instantiate entities objects?

What would the programming model be?
Are entities declared using interfaces/mixins?
Annotated with JPA annotations?

Would querying using JPA and Repository "query methods" be supported?
Would Zest indexing be supported? In addition to JPA querying?
 
Would users be statisfied with that?

How to map Zest state model to/from JPA entities, Property/Association
to beans?

In my experience beans based tools are tied to the JavaBean model and
don't offer extension points to work around it. If Spring Data has
something like an EntityState we could hook into it.
Or we could do it the other way around: user declares a JPA entity as a
bean class with a state interface using the JavaBean convention, plus a
corresponding state interface using the "Zest convention"
(Property<?>/*Association<?>), then assemble the corresponding Entity
Composite with these two interfaces, mixes in the JPA entity impl and we
provide Property<?> *Association<?> mixins and/or concerns that maps
to/from the JavaBean convention. Basically binding Zest and JavaBeans state.

All this feels a bit blury. I think that the resulting programming model
is key, if it's a burden people won't use it. If we invest time on this
to increase adoption we need a clear usage path.

/Paul