Ticket #1009 (closed Defect: fixed)

Opened 5 years ago

Last modified 5 years ago

Avoid association doublets

Reported by: jri Owned by: jri
Priority: Blocker Milestone: Release 4.8.4
Component: DeepaMehta Standard Distribution Version: 4.8.3
Keywords: Cc: dgf, Malte, JuergeN
Complexity: 3 Area: Robustness
Module: deepamehta-core

Description

DM should prohibit to create the same association twice. Serious malfunctions can happen if the association has an operational semantics. In particular creating the same Membership association twice renders that account unusable!

Change History

comment:1 Changed 5 years ago by jri

  • Status changed from new to accepted

comment:2 Changed 5 years ago by jri

  • Area set to Robustness

comment:3 Changed 5 years ago by Jörg Richter <jri@…>

In 17805702883aa0058af1a4824759894ff6609893/deepamehta:

Core: association doublet check on update (#1009).

An update-association operation is rejected if it would result in a association doublet.
The doublet check involves these factors:

  • Association Type
  • Both Topics
  • Both Role Types

Note: the doublette check is performed only if both players are topic players.

See #1009.

comment:4 Changed 5 years ago by Jörg Richter <jri@…>

In b2696777d04c7d6c4be94445508e38635a8d2a1a/deepamehta:

Core: internal API uses more impl objects (#1009).

See #1009.

comment:5 Changed 5 years ago by Jörg Richter <jri@…>

In 85cf68a4edb9adcc5cbe4b6fa861f79f52b19f60/deepamehta:

Core internal: more instantiate() calls (#1009).

See #1009.

comment:6 Changed 5 years ago by Jörg Richter <jri@…>

In 3524e8bb0dcf0de2ebe44283cc5ff5167474859c/deepamehta:

Core: add internal pre/post create hooks (#1009).

See #1009.

comment:7 Changed 5 years ago by Jörg Richter <jri@…>

In 0872e9a5268980b55ad302f6f923aee1967ee253/deepamehta:

Core: association doublet check on create (#1009).

See #1009.

comment:8 Changed 5 years ago by Jörg Richter <jri@…>

In a397b3140d937f3d59ede0f00cad476e2342a65e/deepamehta:

Webclient: recover on create-assoc fail (#1009).

See #1009.

comment:9 Changed 5 years ago by Jörg Richter <jri@…>

In c863e497259354ea8b3526b4d7416b101bdbe7e3/deepamehta:

Core: fix association duplicate check (#1009).

At the moment the duplicate check is performed only if both topic players are referenced by-ID (instead by-URI).

See #1009.

comment:10 Changed 5 years ago by Jörg Richter <jri@…>

In ed28f060dc4ba899d9dd763aa624b385a1e57d23/deepamehta:

Core: revise association duplicate check (#1009).

An association is only regarded as a duplicate if the original association is actually READable by the current user.
That is e.g. user A is not prevented to create an association if User B created such an association already, but privately.

See #1009.

comment:11 Changed 5 years ago by jri

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

comment:12 Changed 5 years ago by Malte

From my current observation, as of this fix, creating a "Membership" or a "Notification Subscription" has become impossible between Username and Workspace as soon as any simple "dm4.core.association" already exists between these two.

An error is thrown to the user if one wants to create a "Membership" between a "Username" and a "Workspace" using the Webclient (when a simple assoc exists).

The only workaround is to retype the existing association to a "Membership" and re-creating the simple assocation which connected the two topics before. Is there a case we would want to disallow many simple associations between two topics? I do not think that "dm4.core.assocations" should be regarded as carrying "operational semantics."

Just wanted to let you know.

Last edited 5 years ago by Malte (previous) (diff)

comment:13 Changed 5 years ago by JuergeN

Same problem here: I need to model a contract with two coutries as partners. I want to create two custom assoc-devs, on for signing partner and one for issuer. At the moment I cannot do that, because systems claims that the assoc dev already exists. This is a very critical bug!

comment:14 Changed 5 years ago by JuergeN

  • Priority changed from Major to Blocker

comment:15 Changed 5 years ago by jri

  • Status changed from closed to reopened
  • Resolution fixed deleted

Confirmed!

The envisioned fix is to involve the association value in the duplicate check as well.
The duplicate check would involve these factors then:

  • Association Type
  • Association Value <-- new
  • Both Topic IDs
  • Both Role Types
  • READability

As a consequence you'll be able then to create 2 (or more) congruent associations as long as they are differentiated by its value.

(I see no point in having congruent associations when they are not distinguishable in any way.)

Hint: the association value is that one displayed alongside the association (on the canvas).

comment:16 Changed 5 years ago by Malte

How i see this issue is that, the way the webclient works, one does not even have a chance to specify a different type or value for the second assoc. Just try it. That is the issue i described in my comment. "As soon as any simple "dm4.core.association" already exists between two" players no further association can be draw as the webclient first (always) create a "dm4.core.association" which the user (normally) would then be able to specificy/retype etc..

comment:18 Changed 5 years ago by Jörg Richter <jri@…>

In 851d2aeb9226731ebb4c703818d7d323f5e5909c/deepamehta:

Core fix: assoc dupl check involves value (#1009).

The association duplicate check involves the association value as well.
That is, two congruent associations can exist as long as they are differentiated by its value.

See #1009.

comment:19 Changed 5 years ago by Malte

Cool, works fine for me now!

comment:20 Changed 5 years ago by jri

  • Status changed from reopened to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.