What I mean is that this starts with a Polygene model and it will create
SQL tables.
Why not the other way around?
Well, you will immediately descend into the rabbit hole where Hibernate is.
With incomprehensibly complex mappings of tables to arbitrary sections of
code, simply not robust enough to ensure solid design. But the SQL model
that we end up with is neat and in the spirit of SQL, unlike the current
KeyValue use of SQL in the entitystore-sql.
That said, adding some feature to the above (such as table/column name
mappings) would allow creation of tool (interactive or declarative) to take
a DB schema and generate the Polygene model from it, to the extent that it
is possible. However, there will be constructs not achievable to fit the
Polygene model, and it is likely that any DB would need additional tables
and columns to accommodate a Polygene model, for instance things like
entity versioning, lastmodifed, and others.
Furthermore, it might be reasonable to capture additional requirements via
JOOQ, and increase the support of consuming/feeding JOOQ, either by getting
JOOQ to understand Polygene models, or the other way around. Getting JOOQ
to understand Polygene seems possible, albeit not trivial, so I am not sure
of the ambition level here. What's important to realize is that it is
outside the domain of "Entity Stores" and UnitOfWork managed persistence.
(I am already feeling the pain, that JOOQ seems to require the transaction
to be within a single JOOQ method call, when we need the prepare() and
commit() in separate calls, initiated from UnitOfWork)
So, loads of work to do, but I want to focus on one step at a time, a step
that is not endlessly complex to satisfy.
Cheers
Niclas
On Mon, May 8, 2017 at 3:59 PM, Jiri Jetmar <[email protected]>
wrote:
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.
Cheers,
jj
2017-05-06 10:25 GMT+02:00 Niclas Hedhman <[email protected]>:
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
