polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <p...@nosphere.org>
Subject Re: JPA revisited
Date Sat, 22 Oct 2016 14:26:11 GMT
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.



Mime
View raw message