Skip to content

Modifying a child template results in an inconsistency in networks made with child #237

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
knoxsp opened this issue Oct 18, 2024 · 2 comments · Fixed by #244
Closed

Modifying a child template results in an inconsistency in networks made with child #237

knoxsp opened this issue Oct 18, 2024 · 2 comments · Fixed by #244
Assignees

Comments

@knoxsp
Copy link
Contributor

knoxsp commented Oct 18, 2024

Consider the following:

  1. Create a template (Template A), with node type Type A. It has an ID of 123
  2. Create a child template Template A Child
  3. Create a network, with node Node A using Type A. Type A is defined on the Template A
  4. In Template B, create a subclass of Type A -- This has an ID of 789

This results in:

  • Type A has ID of 123
  • Type A Child has id of 789
  • Node A' refers to 123`
  • Network A refers to Template B

When requesting Template B, there is no node type with 123, thus resulting in a mismatch between the network and template.

Current Outcome
We now have a network, which is defined as using 'Template B`, but with one of its nodes referring to the Superclass of a node defined withing it, rather than the subclass.

Desired Outcome
Node A in Network A references the child type, either with a HARD reference, or with a SOFT reference -- meaning:

  • When creating a subclass of a node in a child template, we update all references to the parent node type in networks which reference the child template
  • When requesting a child template, we keep a record of all parent node types (there can be more than one), and leave it to the application to figure out what to do:
    For example, the node_type in template B when returned would look like
{
"id": 789,
"name": "Type A",
"parent_ids": [123]
...
}
@pmslavin
Copy link
Contributor

After discussion, the approach of updating references seems likely to obscure the relationship between parent and child types so clients should be presented with a list of parent ids when retrieving type information.

@knoxsp
Copy link
Contributor Author

knoxsp commented Oct 21, 2024

Should this then be accompanied by a function to retrieve types en-mass, so all parent types can be retrieved?
And if this is the case, how do we ensure the correct type inheritance on the client side? For example, if the parent_ids list is [100, 200, 300], can we guarantee that 200 is a child of 100 and 300 is a child of 100?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants