Redefine Contacts data model

[jri]

Since we have association definitions with Custom Association Types (#341) the Contacts data model should make use of it in order to remove the intermediate Address Entry topics between a Person/Institution? and an Address.

Model Address Entry as an Association Type instead (a composite one, with Address Label as child type) and use it as the Custom Association Type for the association definition that (now directly!) connect Person/Institution? with Address.

Do the same for the Phone model. Replace the Phone Entry topic type by an association type.

Provide a migration that converts existing Contacts data.

[Jörg Richter <jri@…>]

In 01fc6b2002518edfa12014c96d74fc07e96fd1de/deepamehta:

Redefine Contacts model (#779).

The topic types Phone Entry and Address Entry are replaced by respective association types. As a consequence the intermediate Phone Entry and Address Entry topics disappear.

No migration is yet provided to convert existing Contacts data.

One new problem arises with Custom Association Types in conjunction with detail panel rendering: the field formerly labeled "Phone" (which holds the actual phone number) is now accidentally labeled "Phone Entry". That is because of the current rendering rule, which is: if a simple (child) field is connected via an association definition which has a Custom Association Type set, then label the simple field with the name of the Custom Association Type instead of the name of the child type. This rule was made with the "Day of Birth"/"Day of Death" example scenario in mind which involves 2 association definitions with the same child type -- "Date" -- but differentiated via the 2 custom association types "Day of Birth"/"Day of Death". In this case the 2 fields are expected to be labeled "Day of Birth"/"Day of Death" instead of just "Date".

The new Phone Entry model reveals that this rendering rule does not hold in general.

Note: with composite child types in contrast this problem does not occur as a composite box in the detail panel, e.g. Address, is never labeled. Only the simple fields are.

=> We might be required to conceive another rendering rule.

This let the question arise if it is possible at all to derive the generic detail panel rendering solely through the data model or if we are required to enhance the data model with view configuration data.

See #779.

[Jörg Richter <jri@…>]

In 27ec33562f269ba1016bd1c8e3b5a335f0bf60d8/deepamehta:

Core API: change add/removeAssocDef (#779).

CHANGES

Core API:

3 methods changed in Type interface:

Type addAssocDef(...)
Type addAssocDefBefore(...)
Type removeAssocDef(...)

These methods return the Type object itself (formerly void).
This supports method chaining.

See #779.

[Jörg Richter <jri@…>]

In 6f7a9b8c5d2e7729989556f7d8947f651ab25f3b/deepamehta:

Add migration to convert Contacts data (#779).

A migration is added that converts pre-4.6 Contacts data to the 4.6 Contacts model. The 4.6 Contacts model basically replaces the topic types Phone Entry and Address Entry by respective association types.

TODO: convert the Phone Label and Address Label info as well. These are not yet converted.

See #779.

[jri]

The Contacts migration is now complete.
Existing Phone Label and Address Label data is converted properly.

=> Please help testing the upgrade process!

You can upgrade any stable DM installation (from 4.1 to 4.5) to 4.6-SNAPSHOT.
Just copy your deepamehta-db folder before starting 4.6-SNAPSHOT.

While upgrading the Contacts model is redefined (basically the topic types Phone Entry and Address Entry are replaced by respective association types) and all existing Contacts data is converted accordingly. The actual Phone and Address topics (instances) are retained and reconnected according to the new model. They are not recreated. That means the Geo Coordinate facets are retained as well and no further Geocoder lookups are performed.

After upgrading all your Contacts data is supposed to appear exactly as it was before.
You can see that e.g. a Person is now connected with Phone/Address? topics directly, utilizing the respective Entry custom association types (see #341).

[Jörg Richter <jri@…>]

In a854980087827d6e0a573d17b65bacedfee8910a/deepamehta:

Webclient: custom assoc type label rule (#341).

The detail panel renders the name of the custom association type as the child topic's field label (instead of the child type's name) if all conditions are met:

1. the child type is simple
2. a custom association type is set
3. the custom association type is simple

New is the 3rd condition.

This rule is considered generally applicable and to work well with all kinds of application models.
At least it works reasonable with these example models:

• Child type is "Phone" (simple) and custom association type is "Phone Entry" (composite). -> The Phone field is labeled "Phone" then.

• Child type is "Date" (simple) and custom association type is "Birthday" (simple). -> The Date field is labeled "Birthday" then.

• Child type is "Association Type" (a meta type, technically simple) and custom association type is "Custom Association Type" (simple). -> The Association Type field is labeled "Custom Association Type" then.

The latter example shows part of DM's meta model definition. Click an association definition instance to see the effect in the detail panel.

Thank you, JuergeN, for comming up with this label rule!

See #341.
See #779.