[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] The modification problem gets worse...
Mmmmm, I beg to differ. The modify action does have the ability to delete specified values from a multi-valued attribute. Quoting RFC2251, Section 4.6 (Modify Operation): "delete: delete values listed from the given attribute, removing the entire attribute if no values are listed, or if all current values of the attribute are listed for deletion" -- Steve -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Thursday, March 13, 2003 1:24 PM To: Steve Anderson Cc: Jeff Bohren; provision@lists.oasis-open.org Subject: RE: [provision] The modification problem gets worse... Steve, Thanks for all the help. All kidding aside, there is no ability to delete specific values in the current SPML, it uses DSML modifications which only allow for attributes to be deleted, added or replaced in total. My scenario still holds because you will not get the "value not found" or "value already exists" errors that you are relying on. Gerry |---------+----------------------------> | | "Steve Anderson" | | | <sanderson@openne| | | twork.com> | | | | | | 03/13/2003 10:17 | | | AM | | | | |---------+----------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: Gearard Woods/Irvine/IBM@IBMUS, "Jeff Bohren" <jbohren@opennetwork.com> | | cc: <provision@lists.oasis-open.org> | | Subject: RE: [provision] The modification problem gets worse... | | | >------------------------------------------------------------------------------------------------------------------------------| I've been following this thread, and it think Gerry's example here actually illustrates Jeff's point. I'll take a stab at explaining ... In Gerry's example, after initial creation, two different RA's want to change Item B. The first, RA1, wants to replace both 'values' (3,4) with two new values (5,6). The second RA, RA2, only wants to replace value 4 with value 5. RA1 executes first, followed by RA2. In Gerry's example, it appears that the modifications can only be done by supplying the whole set (3,5), so the resultant set is just that -- (3,5). The problem is that value 6 has been inadvertently replaced with value 3. In Jeff's approach, the RA2 can perform the following: - Modify B: remove value 4 - result: Value not found -- interpreted by RA2 to be fine, since this is the desired result anyway - Modify B: add value 5 - result: Value already exists -- interpreted by RA2 to be fine, since this is the desired result anyway The final value set for B is (5,6). No corruption. Hope this helps. -- Steve -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Thursday, March 13, 2003 12:56 PM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: Re: [provision] The modification problem gets worse... Jeff, Your argument here and in your previous message is predicated on the assumption that the RAs in my scenario hold the state of the data while in yours they do not. In yours they simply request a modification that is independent of the current state of the data. You argue that this is not a race condition problem and that your scenario will not suffer from it. Let's go through it again using your implementation: RA 1 Entry RA2 create A: 1,2 B: 3,4 read A:1,2 B:3,4 replace B: 5,6 A:1,2 B:5,6 replace B:3,5 A:1,2 B:3,5 This is how the current specification works and according to you this is fine. I'm not sure that I see much of a difference in the end result. Please explain. Gerry |---------+----------------------------> | | Jeff Bohren | | | <jbohren@opennetw| | | ork.com> | | | | | | 03/13/2003 05:22 | | | AM | | | | |---------+----------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: provision@lists.oasis-open.org | | cc: | | Subject: [provision] The modification problem gets worse... | | | >------------------------------------------------------------------------------------------------------------------------------| In a previous posting I have shown how the current proposal by Gerry Woods will cause data corruption when doing modifications. I have shown this using a very simple case. Gerry has suggested that this could be overcome by a modification mechanism that uses XPath in combination with ldap like modification semantics. Although this alternative has not been fully fleshed out, it will not work either. Even theoretically it will fail. Let me explain why. Suppose a record has data that looks like: <A> <B> <C>foo1</C> <C>foo2</C> <C>foo3</C> </B> <B> <C>foo4</C> <C>foo5</C> <C>foo6</C> <B> </A> No suppose RA1 wants to change the first B component. It would have to issues a modification request with an XPath that refers to B where B has foo1, foo2, and foo3. Now suppose the modification changes the record so that it looks like: <A> <B> <C>foo1</C> <C>bar8</C> <C>foo3</C> </B> <B> <C>foo4</C> <C>foo5</C> <C>foo6</C> <B> </A> Now suppose at a later time RA2 wants to remove the first B component from A. It would have to issues a modification request with an XPath that refers to B where B has foo1, foo2, and foo3. This request would now fail. There is no automatic way for RA2 to reconcile the differences. Jeff Bohren Product Architect OpenNetwork Technologies, Inc ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]