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 
property/asso.
In order for data to be properly normalized, it should reside in *one* 
place.

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.

Mime
View raw message