polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jiri Jetmar <juergen.jet...@gmail.com>
Subject Re: ORM EntityStore
Date Mon, 08 May 2017 07:59:12 GMT
Hi Niclas,

thank you for taking over the ORM topic. We definitely require a
'generally' accepted approach how to deal with persistence !

'NOTE, this is only for "Java Model drives SQL model", but in an
enterprise-friendly way.'

I;m a bit confused with the above expression. From my understanding we need
the opposite direction - a relational model drivers the application related
model. And as we are using Java, we end up with a O-R-M. Or do
I misunderstood something ?

Thank you.


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

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