Thanks for the use cases. But then „create node“ according to your proposal would only work exactly once. A restart of the runtime or just the sling jcr bundle would automatically fail because then the node would already be there when the statement is executed again…. So IMHO only update and updateOrCreate are useful. WDYT, Konrad
> Am 16.12.2022 um 20:42 schrieb Eric Norman <[email protected]>: > > Also, another use case I was thinking of for the "update node" scenario is > if you want to add a mixin to a node that was expected to be already > created elsewhere, if the node doesn't exist yet then your mixin won't get > assigned and you could have indeterminate behavior later. So failing fast > would quickly tell you something is wrong. > > Regards, > -Eric > >> On Fri, Dec 16, 2022 at 11:19 AM Eric Norman <[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) >>> >> >> 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 >>>>> >>>>> >>> >>>
