polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanislav Muhametsin <stanislav.muhamet...@zest.mail.kapsi.fi>
Subject Re: ORM EntityStore
Date Mon, 08 May 2017 13:23:42 GMT
I agree with JJ here, but SQL-leads-Polygene approach is extremely hard 
to do, considering that creating SQL indexing store to fully support all 
stuff that Polygene query engine does is quite demanding already.
But I'm not saying it is impossible - hardly anything is. :)
And it's good that Niclas is starting with simple first step - that way, 
one might learn things that will come handy when making more complex, 
further steps.

Without knowing much about current code structure and big entity-related 
principles of Polygene, I think one big aspect to really try and make 
work is synergy between SQL ES and Indexing.
Currently those are acting as two completely different databases with 
different schemas etc.
But what Niclas talked about in the first e-mail, it sounds like ORM 
approach already covers a big chunk of what current SQL indexing does.
So maybe those two can be e.g. using common schema logic (and thus share 
common code related to RDB initialization etc) at some point?

On 8.5.2017 12:47, Jiri Jetmar wrote:
> Ok, see your point. So what you are saying now is that the first step would
> be a Polygene model that would lead/specify the SQL model in a more SQL-ish
> way.
> That means a more natural/classical SQL schema will be generated - unlike
> the key/value approach that is implemented now.
> I personally would still prefer an SQL-leads-Polygene model, simply because
> generations of developers
> 'trust' in a DB/SQL schema. Further organizational structures within
> companies rely on strict data ownership based on relational schemas. There
> are also tons of tools that support relational schemas - from the
> generation of documentation.. till migration of complex schemas.
> I know that Hibernate is exactly doing the mapping from the OO-World to the
> R-World, offering a large number of features like schema generations, etc..
> And we all know how complex and unpredictable this tool is. There are also
> people that already give up and are simply arguing that when you are in
> enterprise and you have to deal with relational repositories and you have
> simply pay the price and deal with the complexity (complexity ==  'business
> value' and any other competitor has to deal with the same complexity as
> well.)
> In general, this ORM thing has eventually too many points that must be
> considered, so that a 'perfect' and universal solution does not exist...
> Cheers,
> jj
> 2017-05-08 10:28 GMT+02:00 Niclas Hedhman <niclas@hedhman.org>:
>> 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 <juergen.jetmar@gmail.com>
>> 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 <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

View raw message