Ticket #338 (closed Defect: fixed)

Opened 8 years ago

Last modified 7 years ago

An Association's "Instantiation" Association has no type assignment

Reported by: jri Owned by: jri
Priority: Major Milestone: Release 4.1
Component: DeepaMehta Standard Distribution Version: 4.0.12
Keywords: Cc: dgf, Malte
Complexity: 5 Area:
Module: deepamehta-core

Description

An Association's "Instantiation" Association has no type assignment and thus, technically, is no Instantiation. (It works anyway because the respective logic is guided by role types and ignores the missing type assignment.)
By contrast:
A Topic's Instantiation Association *has* a type assignment (to Association Type "Instantiation" obviously).

For association's that type assignment is not stored.
This decision was made in order to cut the vicious circle that occurs because that assignment itself would need a type assignment, and that one too, ...

This missing type assignment has 2 consequences which has proven as a problem for certain applications (or migrations):

  • assoc.getTypeUri() for an association's type assignment association returns "" (instead of "dm4.core.instantiation"). Fetching a type with an empty URI fails.
  • dms.getAssociations("dm4.core.instantiation") returns only "Instantiation" associations of topics's and misses the "Instantiation" associations of associations.

A solution could be to cut the vicious circle one step later.
(Is this really a solution or would it just shift the problem?)

Change History

comment:1 Changed 7 years ago by jri

  • Status changed from new to accepted

comment:2 Changed 7 years ago by Jörg Richter

Core: association metadata index (#389, #338).

The association metadata index basically works. Both, indexing and query. Update is pending.

Core is not yet functional.

Furthermore, in order to determine an object's type the new storage layer doesn't rely on "Instantiation" associations anymore. Instead a "type_uri" property is stored for every object (= Neo4j Node). (The "Instantiation" associations remain to exist).
This provides the basis for solving #338 (An Association's "Instantiation" Association has no type assignment).

Furthermore in Parent POM: we explicitely use an older Surefire version (2.12.4) in order to avoid an exception logging problem introduced in Surefire 2.13

See ticket 389.
See ticket 338.

comment:3 Changed 7 years ago by Jörg Richter

Core: association metadata index (#389, #338).

The association metadata index basically works. Both, indexing and query. Update is pending.

Core is not yet functional.

Furthermore, in order to determine an object's type the new storage layer doesn't rely on "Instantiation" associations anymore. Instead a "type_uri" property is stored for every object (= Neo4j Node). (The "Instantiation" associations remain to exist).
This provides the basis for solving #338 (An Association's "Instantiation" Association has no type assignment).

Furthermore in Parent POM: we explicitely use an older Surefire version (2.12.4) in order to avoid an exception logging problem introduced in Surefire 2.13

See ticket 389.
See ticket 338.

comment:4 Changed 7 years ago by Jörg Richter

  • Status changed from accepted to closed
  • Resolution set to fixed

Extend Core Service API. Also fix #338.

New in DeepaMehtaService?:

Set<Topic> getTopics(String key, SimpleValue? value, boolean fetchComposite, ClientState? clientState)

Fetches topics by key and value. String values can contain wildcards like "*". Index mode dm4.core.key is required.

Furthermore (internal): instantiation traversal is fully qualified. Possible through new storage layer.
Close ticket 338.

Note: See TracTickets for help on using tickets.