I think it is fine to leave out "update node" for now (but you have to keep it in mind for naming the other new instruction to allow for such semantics later on). So I will for now only update https://github.com/apache/sling-org-apache-sling-repoinit-parser/pull/27 <https://github.com/apache/sling-org-apache-sling-repoinit-parser/pull/27> with
Instruction "ensure node" (for creating or updating node(s) with primary and mixin type). WDYT? Konrad > On 19. Dec 2022, at 13:16, Carsten Ziegeler <[email protected]> wrote: > > 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]
