I am removing a variable from a protocol. According to the docs:
https://documentation.noumenadigital.com/tools/migrations/Migration-DSL/Examples/#delete-an-existing-protocol-property
you can use the delete func to remove the state. But this example is also changing the name of the protocol. Do I need to do that if I am not changing anything else? I think I just need to do the retag, nothing else…
Hi Ed,
Let’s dissect that example together
migration("remove property")
.transformProtocol(
currentTypeId = "/app-1.0.0?/example/Before",
targetTypeId = "/app-2.0.0?/example/After",
) {
delete("x")
}
In both the currentTypeId and targetTypeId, the type ID has the following structure
/app: the name defined assystemUnderAudit1.0.0or2.0.0: the version number that is modified by the retag. To perform the protocol transformation, the correct current and target type IDs need to match the ones the migration tool are expecting. This is however not renaming or retagging protocols in iteslf. See note for this below. In your case, there would be two different version numbers between the current and target type ID.example: the package name in NPLBeforeorAfter: the name of the protocol. In your case, it would be both time the same
Note: Here are a few examples of how to rename and discard protocol declarations, including names:
https://documentation.noumenadigital.com/tools/migrations/Migration-DSL/#special-cases
Ok I will make sure I understand.
So the existence of Before in the npl directory, then followed by the existence of After in the next version npl directory, is the reason that the NPL source code gets updated.
Then the way the frame data gets reassigned from the instance of Before to the new After is via this call with transformProtocol, and the delete(x) deletes the var from the frame.
Now going back to my example, unless we call delete(var) within the transform protocol, the frame would get retagged to the correct source code, but the var x would just remain in the frame, never to be referenced again.
Wdyt?
You got 99% right ![]()
Only detail to mention is that if a field is in the data but the target frame does not expect it, the migration will fail.