Meta model: more than one assoc def with the same child type

[jri]

Since we have Custom Association Types in the meta model (#341) it should be possible in a type definition to have more than one assoc def with the same child type, provided the assoc defs use a different custom assoc type.

At the moment e.g. Person can't have 2 assocs defs with City as the child type, with custom assoc types "Born" and "Died" respectively. DM would throw a "Schema ambiguity" exception.

[Jörg Richter <jri@…>]

In cfa64ab27d129d4f99ce96a3cb9be4e70bf9c23e/deepamehta:

Meta model: assocDefs with same child type (#903).

Extended meta model: in a type definition you can have more than one assoc def with the same child type, as long as you use custom assoc types to differentiate them.

Example: topic type "Person" can have 2 assocs defs with "City" as the child type, with custom assoc types "Born" and "Died" respectively. (Technically one custom assoc type would be sufficient in this case as the 2 assoc defs are still distinguishable.)

BREAKING CHANGES

The API signatures are not changed but the semantics is slightly changed. When you refer to a child you must not specifiy a plain child type URI but an assoc def URI. An assoc def URI consists of (the usual) child type URI but possibly qualified by custom assoc type URI.

Java API:

According to the Person example access the 2 cities:

person.getChildTopics().getTopics("dm4.contacts.city#org.biography.born")
person.getChildTopics().getTopics("dm4.contacts.city#org.biography.died")

That is you add a # followed by the custom association type URI to the (usual) child type URI.

Note: if a custom association type is defined you MUST add it as a qualifier when accessing childs, even if no ambiguity would occur:

person.getChildTopics().getTopics("dm4.contacts.address#dm4.contacts.address_entry")

This would be an error:

person.getChildTopics().getTopics("dm4.contacts.address")

To reflect the new semantics of the former childTypeUri parameter it is renamed to assocDefUri in all Core API methods.

Exact definition of an assoc def URI:

• a plain child type URI in case no custom assoc type is set in the respective assoc def.
• a child type URI qualified by custom assoc type URI (separated by #) in case a custom assoc type is set in the respective assoc def.

So, in a lot of cases a plain child type URI can still act as an assoc def URI. In case your data model does not involve custom association types you must not adapt the plugin at all.

Note: in contrast to other URIs an assoc def URI is not globally unique. It is unique only among all assoc defs of a parent type. Think of an assoc def URI as an unique identifier for each of the parent type's assoc defs.

Also a type's Label Configuration now consists of assoc def URIs (instead of plain child type URIs).

Example (in a JSON migration):

"label_config": [
    "dm4.contacts.person_name",
    "dm4.contacts.city#org.biography.born"
]

REST API:

In principle the same as with the Java API applies. That is you must specify assoc def URIs instead of child type URIs when referring to childs.

Example (create a Person):

{
    "type_uri": "dm4.contacts.person",
    "childs": {
        "dm4.contacts.address#dm4.contacts.address_entry": [
            {
                "childs": {
                    "dm4.contacts.street": ...,
                    "dm4.contacts.postal_code": ...,
                    ...
                },
                "assoc": ...
            }
        ],
        "dm4.contacts.phone_number#dm4.contacts.phone_entry": [
            ...
        ],
        ...
    }
}

See #903.

[Jörg Richter <jri@…>]

In 540e56c842c82c1241f9144999fd2c0dd4c6963b/deepamehta:

Core: fix type update/by-URI del refs (#903,#631).

Updating of type defs is refactored.
See also ticket:906#comment:2

New feature: by-URI deletion references (see #631).
To be tested.

Core API:

3 new methods in ChildTopicsModel?:

ChildTopicsModel putDeletionRef(String assocDefUri, long refTopicId)
ChildTopicsModel putDeletionRef(String assocDefUri, String refTopicUri)

ChildTopicsModel addDeletionRef(String assocDefUri, String refTopicUri)

BREAKING CHANGES

Webclient constants:

dm4c.REF_ID_PREFIX  = "ref_id:"     // formerly named REF_PREFIX
dm4c.REF_URI_PREFIX = "ref_uri:"    // new
dm4c.DEL_ID_PREFIX  = "del_id:"     // formerly named DEL_PREFIX
dm4c.DEL_URI_PREFIX = "del_uri:"    // new

See #903.

[Jörg Richter <jri@…>]

In 883db06b5b7db5e498d9e4a23a4c46adc9c77f11/deepamehta:

Core: fix assoc def constructor (#903).

The test are passing again.

See #903.

[Jörg Richter <jri@…>]

In da4ab80702901d94128b576012e33176a289fc28/deepamehta:

Webclient: fix related topics list (#903).

Topics that adhere to a type definition are not shown twice.

See #903.