Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
Message-ID: <580B5796.90807@nosphere.org>
Date: Sat, 22 Oct 2016 14:12:06 +0200
From: Paul Merlin <paul@nosphere.org>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: dev@zest.apache.org
Subject: Re: JPA revisited
References: <CADmm+KdHS1AS4DUcnDfLBdXSKFT5eV3KJmpx23q_cngHgYbesA@mail.gmail.com>
In-Reply-To: <CADmm+KdHS1AS4DUcnDfLBdXSKFT5eV3KJmpx23q_cngHgYbesA@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------050709000909060001060201"
archived-at: Sat, 22 Oct 2016 12:12:23 -0000

--------------050709000909060001060201
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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


--------------050709000909060001060201--