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: JPA?
Date Wed, 21 Sep 2016 13:16:48 GMT
On 21.9.2016 16:01, Niclas Hedhman wrote:
> Thanks a lot Stan for the overview picture, which is sometimes hard to
> acquire by looking at the code.

No problems at all!
Especially it can be hard to acquire because the code is really old and 
poorly documented. :)

> 3. All state that is not exposed by an EntityType is still expected to be
> preserved if an Entity of that EntityType is updated. The trick is that
> some EntityTypes overlap and many don't, and currently there is no way to
> know when EntityTypes overlap and need to share a table for
> Property/Association. IF that were to be introduced somehow, then one table
> per over-arching entity typo could be created with a column per
> Property/Association, and possibly even manage a separate table for each of
> ManyAssoc/NamedAssoc dynamically. I think that in reality that is always
> the case, both for myself and what I remember from StreamFlow. The problem
> is that some small subtypes will cross tables, and it is this feature that
> we could decide to prevent for RDBMS used as 1c above.

Actually, this is the reason why SQL indexing has one table per 
In order for data to be properly normalized, it should reside in *one* 

To elaborate, suppose you have:
interface MyBaseEntity {
   Property<String> someProperty();

interface MySubEntity extends MyBaseEntity {
   Property<String> someOtherProperty();

interface MyAnotherSubEntity extends MyBaseEntity {
   Property<String> yetAnotherProperty();

If you have added "MySubEntity" and "MyAnotherSubEntity" types as entity 
composites in your Zest application setup, then current SQL indexing 
will generate exactly *one* table for MyBaseEntity.someProperty property.
That is, even when it is seen as "double" - being present in both 
MySubEntity and MyAnotherSubEntity, in database it still exists in 
exactly one place - the dedicated table.
I had to do this in quite early stage of the code, otherwise the 
indexing tests would not have passed for SQL indexing. :)

Niclas, did I talk about the same thing you were talking in #3? :)

> 4. For 1b above, the existing EntityStore might be the fastest option and
> for some people that is reasonable choice. However, data lives for long,
> and we should in that case make sure that all the metadata that is in the
> Zest type system, is also stored alongside this compact, serialized format,
> and that we have a generic tool that can read 1b storage type and create a
> 1c output, in case people change their mind, throw away Zest or other
> unforeseen circumstances.
> I hope you all get a feel for my thinking here... The default Zest type
> system is way too "cool" for RDBMS, but we could introduce some limitations
> to better support RDBMS in an enterprise setting.

I think the current Zest data model is very nice.
Any limitations to be introduced should be optional - enabled by user of 
Zest, if (s)he so requires.

In the end, it's all about trade-offs: You can always have the 1b/c 
options, if you compromise disk space/performance/sync time.

Related to metadata: SQL indexing stores that as well, in auxiliary 
tables of the schema.
That had to be done in order to detect the changes in entity types: e.g. 
adding a new property to entity type, and SQL indexing automatically 
generating a new table for that.

View raw message