Ticket #338 (closed Defect: fixed)
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:2 Changed 12 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 12 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 12 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.
