polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Martini <sandro.mart...@gmail.com>
Subject Re: ORM EntityStore
Date Sat, 06 May 2017 18:26:53 GMT
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.


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".
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java

View raw message