Repository navigation
Node update: do we allow concept change? #69
Description
When we update a node -- for example as part of the bulk API -- do we want to allow a change of the concept?
This way, we can keep references alive even though something changes, say, from a global constant to a function call. Obviously, the updated node must contain all the children and properties defined by the new concept.
Alternatively, the server should refuse the update if the concept is changed.
Activity
joswarmer commentedon Feb 2, 2023
Argument against allowing this: changing the concept might easily invalidate references to the node, as it might not have the type expected at the location of the reference.
dslmeinte commentedon Feb 2, 2023
I think this should probably tie in with the idea of multiple levels of conformance/compliance/validity of a model - i.e. roughly: 1) OK at transport level, 2) references resolve, 3) conforms to a given metamodel, 4) constraints are met.
The DI layer probably shouldn't have to care about a concept change, but a programmatic one certainly would.
ftomassetti commentedon Feb 10, 2023
Is this distinguishable from the case in which a Node is deleted and a Node with the same ID is recreated, but with a different Concept? I am thinking of cases in which the ID is determined based on the structure (for example, for ASTs)
enikao commentedon Feb 10, 2023
Not in the case of bulk update, as two nodes with the same id are considered identical (see #31).
For delta changes, one would be (delete + create), the other one (change).
enikao commentedon Jan 28, 2024
If model migration is executed by a (regular) processor, we must allow concept change -- the migrator would at least change the concept from
{langX, v1, conceptY}to{langX, v2, conceptY}. According to #213, that's a concept change.joswarmer commentedon Jan 29, 2024
Sounds like we need this, the current lionweb-repository does not allow this, or better said, it ignores the classifier once a node has been stored for the first time.
enikao commentedon Mar 7, 2024
Decision: Repository MUST support meta-pointer change.
This means that an update command can send an already existing node id with a different
classifierthan the existing node.(Decided on 2024-03-01)
Rationale: