I understand you points and thanks for the clarification about the meaning of the exception. My suggestion was not to change the current delete, but to add to it another flag, which will "silence" the exceptions in the case where the transaction started when the Node existed, and ended when it didn't exist anymore. Default behavior would stay the same. Cleanup code can potentially do the same deletion twice, and I think it makes sense to allow it to pass this "permissive" flag.
-----Original Message----- From: Robert Varga [mailto:n...@hq.sk] Sent: Friday, January 20, 2017 2:46 AM To: Sela, Guy <guy.s...@hpe.com>; controller-dev@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; Tom Pantelis <tompante...@gmail.com> Subject: Re: Deleting a node from MD-SAL that doesn't exist / already deleted On 01/19/2017 07:03 PM, Robert Varga wrote: > The question you need to answer to solve the problem you are seeing is: > why has the path disappeared? ... and please don't get me wrong, I am not inherently opposed to defining new operations, but it is an immensely expensive change. This would have to be a new operation, not a LogicalOperation.DELETE, as we cannot ever change LogicalOperation semantics (except for pure bugfixes). It needs to have it's semantics completely defined. By completely defined I mean the following: - semantic meaning, preconditions and postconditions for a single operation for all SchemaNode types (user-ordered leaf-lists are fun) - define version-conflict resolution rules for both missing-node case and conflicting tree/subtree versions mismatches, including traversed parent nodes - evaluate impact on ModificationType (any change affects all DTCL users) - provide minimal implementation of a proof of associativity (for intra-transaction state tracking compression) ... after which we can worry about implementing it, then test, then write a migration guide for API users, then audit all known callsites, making sure they are doing the right thing, and then start planning a rollout. Regards, Robert P.S.: If we decide do that kind of effort, we should do LogicalOperation.CREATE, too, as that will amortize the work. _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
