polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: ORM EntityStore
Date Sun, 07 May 2017 00:52:48 GMT
Thanks for the views, and Slick seems to be (correct me if I am wrong) the
equivalent of JOOQ in Java. I would even argue that Slick is more "masking
it with another custom language" than JOOQ is trying to do;

Result<Record> baseEntityResult = dsl
    .from( entitiesTable )
    .where( identityColumn.eq( reference.toURI() ) )

BUT, the interesting point is whether the best way forward is to see if it
is possible to make JOOQ handle Polygene entities instead of Java Beans.
JOOQ operates in two "modes", either the lower level (which I intended to
use) where the programmer needs to ensure that everything is correct, or in
a higher/generated mode, where type-safety is achieved with generation of
code from a model "somehow" (I haven't studied the details, so know very
little about it). This is likely a great undertaking, and probably more
effort than I can cope with in the short run.

Another "option" is to simply expose the "Result-to-Object" mapping phase,
so people could take any arbitrary JOOQ Result<Record> and push that into
Polygene entities. That is very easy to do, BUT one risk that data is
missing in the Result<Record> and hence corrupts the data over time. This
could be leveraged by map into Values instead, so they can't be modified
and can't be saved. That would have the interesting side-effect that it is
incredibly useful for a View Model in a CQRS set up. Also, if that Value
has ManyAssociation, then getting those (within a UnitOfWork) would neatly
retrieve those entities (albeit one-by-one). Not sure it would be possible
to have a ManyAssocation returned as a query result, but maybe it is also
an option.

What I don't like is to only provide "manual" handling, since that will
lead to data corruption as people forget to include fields and handle
mapping tables (Named/ManyAssociation) correctly. So I can contemplate the
second option above, into Values. That seems rather safe, yet opens the
query engine (JOOQ) to full potential, I think.


On Sun, May 7, 2017 at 2:26 AM, Sandro Martini <sandro.martini@gmail.com>

> Hi Niclas,
> I was tired of Hibernate too :-) ...
> I think that your proposal looks very interesting, an approach more
> related to code to me looks better (and more Java oriented) than many
> current products ... but an hard point could be to find a way to let
> developers write SQL code if/when needed, instead of masking it with
> another (custom) language like HQL or others similar.
> Just to have some idea, there is a great product from the Scala stack:
> [Slick](http://slick.lightbend.com/) that has a similar approach,
> maybe some idea can arise.
> Hope this helps.
> Bye
> 2017-05-06 10:25 GMT+02:00 Niclas Hedhman <niclas@hedhman.org>:
> > Gang,
> >
> > I have gotten overly angry with Hibernate on $dayjob, and decided to
> take a
> > look at what a ORM-ish implementation in Polygene would look like. And it
> > was easier than I expected, so...
> >
> > Pretty simple,
> >
> > 0. One "types table" that keep tracks of all types. Content of this is
> > probably fully cached.
> >
> > 1. One type table for each MixinType (except HasIdentity)
> >
> > 2. One "base entity" table with the Identity, lastmodifed and so on
> stuff.
> >
> > 3. Use a different (internal) identity for the "value", which makes it
> easy
> > to fully support non-destructive updates.
> >
> > 4. Property->SQL on basic types, and Serialization kick in on
> > ValueComposites.
> >
> > 5. Association->SQL is simply a VARCHAR
> >
> > 6. Named/ManyAssociation->SQL needs an intermediate table per assoc
> (naming
> > is trouble some)
> >
> > 7. get() becomes a SELECT with one join per mixin type
> >
> > 8. new/update is bunch of INSERT (if non-destructive is used) SQL
> > statement, one for each mixin type plus an UPDATE for "base entity".
> >
> > 9.  Named/ManyAssociations will also be an INSERT with many values.
> >
> > 10. JOOQ is awfully helpful in making this, and I am trying to modularize
> > it so that people can customize it if needed, at Composite Methods level,
> > either by Concerns or overriding Mixin methods.
> >
> > 11. IF destructive mode is wanted, I suggest that DELETE statements are
> > issued to remove old stuff, which makes both modes semantically
> identical,
> > and not a big deal if something is accidentally not removed.
> >
> > And that is pretty much it. Fairly straight forward, and a far cry from
> the
> > complexity of Hibernate, guessing what it does and why.
> >
> > NOTE, this is only for "Java Model drives SQL model", but in an
> > enterprise-friendly way. I hope that this can be a big "adoption driver".
> >
> > WDYAT?
> >
> >
> > Cheers
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org - New Energy for Java

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

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