Open nezaniel opened 1 month ago
Clever solution, +1 by reading. Just 2 nitpicks, potentially as conversation starter – feel free to ignore.
One thing I wonder: IIRC we plan to store the expanded super node type names with the creation event. That might make parts of this redundant!?
It will prevent future events from having classification unknown, yes. But sadly we cannot safely apply the SuperNodeTypes to past events because we don't know the past state anymore, so we still need to handle that case
But sadly we cannot safely apply the SuperNodeTypes to past events because we don't know the past state anymore, so we still need to handle that case
i would like to think further into that direction if its really not possible as this will prevent us from this complexity. But for that i have think a little more :D
Proof that this cannot work:
Now try to assign supertypes to event 1
Also yet tbd: what to do if something is a site AND a shortcut
resolves #5077
This introduces the concept of placeholders for document uri paths. If the DocumentUriPathProjection encounters an unknown node type - which may happen during replay - it creates a placeholder instead of ignoring it. Placeholders are not evaluated in routing, but are transformed to actual uri paths once the respective node aggregate has been changed to type document, shortcut or site.
Upgrade instructions
needs both cr:setup and cr:projectionreplay documenturipath
Review instructions
We still need to decide on how to deal with the node type changes
Checklist
FEATURE|TASK|BUGFIX
!!!
and have upgrade-instructions