How about "ensure node"? It's shorter than "updateOrCreate node", which to me seems likely the most common case.
Regards Julian PS: my preference is also with deprecating "create path" in favour of a new clearly defined instruction. On Mon, Dec 19, 2022 at 7:21 AM Konrad Windszus <konra...@gmx.de> wrote: > > 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 <enor...@apache.org>: > > > > 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 <enor...@apache.org> 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 <k...@apache.org> 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 <enor...@apache.org> 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 <julian.resc...@gmx.de> > >>>> wrote: > >>>> > >>>>> On 16.12.2022 14:38, Konrad Windszus wrote: > >>>>>> > >>>>>>> On 16. Dec 2022, at 14:31, Bertrand Delacretaz < > >>> bdelacre...@apache.org> > >>>>> 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 > >>>>> > >>>>> > >>> > >>> >
