> > 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) >
Yes, that is kind of the point. You can't possibly conceive every possible use case, so just make the language generic enough to satisfy a broad set of use cases. 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. (We also don’t have anything like that for set properties AFAIK) > I think the "[set|default] propertyName ..." syntax is conceptually similar. In that, the "default" operator would only modify the value if it does not already have a non-default value. Regards, -Eric On Fri, Dec 16, 2022 at 11:04 AM Konrad Windszus <[email protected]> wrote: > 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 > >> > >> > >
