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.

Reply via email to