How about we go there when such a use case comes up in reality?
Regards
Carsten
Am 19.12.2022 um 13:09 schrieb Konrad Windszus:
Please read the full mailing list thread.
This were the use cases brought up by Eric
"I can envision a highly modular distribution in which two
modules (from different owners) may accidentally have paths that collide.
So I can see how a repoinit that would fail fast in that scenario could be
useful. In other words, if someone else already created a path (with the
wrong types) that you are not expecting to be there, then failing right
away seems like a reasonable solution.”
Konrad
On 19. Dec 2022, at 12:50, Bertrand Delacretaz <[email protected]> wrote:
Hi,
I agree with deprecating "create path" and implementing new instructions.
But I'm not sure why you would need two new instructions:
Konrad Windszus <[email protected]> wrote:
...
a) ensure node (for creating or updating node(s) with primary and mixin type)
b) update node (for just updating existing node(s) with primary and mixin type).
...
In both cases, you want the specified nodes to be exactly as described
in the statement, so why two instructions?
What would "update node" do if not all nodes exist yet, fail? Do
nothing? Both are not good IMO.
Whoever writes the repoinit script specifies an end state, I don't
think they care about the previous state, so I think just "create
node" is sufficient and simpler to implement.
But it's actually not a single node that's being created or updated,
it's the whole subtree, when you write something like
create node (nt:folder) /one(mixin nt:art)/step(mixin nt:dance)/two/steps
You're actually touching up to 4 nodes...I think "create nodes" or
"set nodes" is a better name for this new instruction.
-Bertrand
--
Carsten Ziegeler
Adobe
[email protected]
