Sounds good to me, so that would leave us with two new statements: 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).
I will update my PR at https://github.com/apache/sling-org-apache-sling-repoinit-parser/pull/27 <https://github.com/apache/sling-org-apache-sling-repoinit-parser/pull/27> accordingly. Konrad > On 19. Dec 2022, at 11:44, Julian Sedding <[email protected]> wrote: > > 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 <[email protected]> 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 <[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 >>>>>>> >>>>>>> >>>>> >>>>> >>
