TBH I don’t yet see use cases for failing when the node does already exist (create node in your proposal) nor for failing when the node does not exist (update node) Can you share some examples you have in mind which would benefit from that functionality? (We also don’t have anything like that for set properties AFAIK)
Thanks, Konrad > On 16. Dec 2022, at 19:59, Eric Norman <[email protected]> wrote: > > For me the proposed "strict" modifier doesn't seem obvious what it is going > to do. > > I would prefer a more verbose language with several options and let me > choose which one to use. In other words, deprecate the original > (ambiguous) "create path" syntax and replace it with a new > "[create|update|createOrUpdate] node" syntax that is more clear what is > expected to happen. > > For example: > > # the original syntax (leave as is for backward compatibility). > # This would be similar to the "createOrUpdate" use case without any > # attempts to change the primaryNodeType and mixinTypes of already > existing nodes > create path (nt:folder) /one(mixin nt:art)/step(mixin nt:dance)/two/steps > > # > ---------------------------------------------------------------------------------------- > # ----------------- New replacement > syntax ----------------------------------------------- > # > ---------------------------------------------------------------------------------------- > > # new syntax that will fail if any of the paths already exist > create node (nt:folder) /one(mixin nt:art)/step(mixin nt:dance)/two/steps > > # new syntax that will fail if any of the affected paths do not already > exist > # and would attempt to change the primaryNodeType and mixinTypes where > specified > update node (nt:folder) /one(mixin nt:art)/step(mixin nt:dance)/two/steps > > # new syntax that will create nodes that do not yet exist and update nodes > that do already exist > # by attempting to change the primaryNodeType and mixinTypes where > specified > createOrUpdate node (nt:folder) /one(mixin > nt:art)/step(mixin nt:dance)/two/steps > > > > Regards, > -Eric > > On Fri, Dec 16, 2022 at 6:53 AM Julian Reschke <[email protected]> > wrote: > >> On 16.12.2022 14:38, Konrad Windszus wrote: >>> >>>> On 16. Dec 2022, at 14:31, Bertrand Delacretaz <[email protected]> >> wrote: >>>> >>>> So in the case of SLING-11736 I have proposed adding a [strict] option >>>> to "create path", exemple: >>>> >>>> create path [strict] (nt:folder) /one(mixin nt:art)/step(mixin >>>> nt:dance)/two/steps >>>> >>>> which activates the improved behavior proposed in that ticket >>>> (adjusting primary + mixin types of existing nodes if needed), without >>>> changing the behavior for existing code. >>>> >>>> I think that's inline with the above principles, WDYT? >>>> >>>> -Bertrand >>> >>> >>> I don’t like this for the reasons outlined at >> https://github.com/apache/sling-org-apache-sling-jcr-repoinit/pull/41#issuecomment-1354488929 >>> >>> "From an end user perspective deprecating one statement and introducing >> a new one with a more concise name is better than just adding the option >> strict to existing statements with fuzzy names like “path”: >>> >>> Also I consider the statement name “create path” very inconcise as >> adding properties in JCR is also creating a “path”. >>> Since for backwards compatibility reasons users of the existing “create >> path” which want to leverage the stricter handling in any way have to >> update the statement they should rather replace “create path” by “create >> node” instead of adding a new option “strict”. IMHO that makes the >> statement also easier to read/understand. >> >> Feedback from an innocent bystander: if the command already has a poorly >> chosen name, it really makes sense to add a new command with precisely >> defined semantics and a clear failure mode. >> >> (so, no to adding "strict" here) >> >> Best regards, Julian >> >>
