[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: nested operation attribute interoperability
Andy Bierman <firstname.lastname@example.org> wrote:
> Martin Bjorklund wrote:
> > I agree that top-down processing makes most sense (that's what we do
> > today).
> Let's approach the problem that way.
> Let's remember (I didn't) that it is the contents
> of the target configuration that matters, not the
> child nodes within the PDU request, when testing the
> edit operation for the current node.
> > So, what should the table be? Like this maybe
> > child -> create merge replace delete
> > parent
> > |
> > none V V V V
> > create x V V E-1
> > merge V x V V
> > replace V V x E-1
> > delete E-1 V E-1 x
> merge and replace are not really different in these nesting cases.
> Your E-1 for replace-delete and delete-replace seem wrong
> because there is no existence test for replace.
If replace-delete is interpreted as "first replace parent. then, while
doing the replace, delete the child", the "delete the child" will fail
delete-replace... first delete the parent, then replace the child. If
this does not generate an error, the child would actually be created.
Same goes for delete-merge if this interpretation is used. So maybe
an error should be generated even for delete-merge.
> > The E-1 on delete under replace would be motivated by the fact that
> > replace is first delete, then create. So it should give the same
> > error as delete under create.
> > The only question mark is maybe the last row. Why should merge under
> > delete be allowed? (maybe for convenience; default operation is
> > 'merge', and with this you can do:
> > <user operation="delete">
> > <name>fred</name>
> > </user>
> No -- operations affect the current node and all its children.
> The operation for <name> is 'delete'.
(But is this obvious from the text? Is it this sentence from 7.2 that
defines this behaviour:
The attribute identifies the point in the configuration to perform
> Top-down processing works:
> If there are no <user> nodes in the target data model, then it
> doesn't matter if <name> is present or not -- it is still a
> data-missing error as soon as <user> is processed.
> Since the operation in effect at the next node is a delete on the
> selection node 'fred', if the <user> node did exist, but the entry
> for 'fred' did not exist, the delete test for name=fred fails,
> and a data-missing error is correctly generated.
> If you really did have:
> <user operation="delete">
> <name operation="replace">fred</name>
> This 'replace' would be a NO-OP (V-2 as I interpreted it).
> Since 'replace' and 'merge' do not have existence test errors,
> there is no error generated even if the 'replace' attribute
> is processed. The end result is that the target data model
> is deleted, starting from the node that 'delete' is first seen.
> (Further processing for selection nodes is required of course.)
But this must also depend on the data model.
If name is key in user, this would delete the user fred:
But this wouldn't delete all admin users, would it?
Unless you apply some kind of subtree filtering semantics on the
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.