polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: JPA revisited
Date Sat, 22 Oct 2016 13:19:04 GMT
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.


On Sat, Oct 22, 2016 at 8:12 PM, Paul Merlin <paul@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message