Change in RmAttributeValue

Mar 29, 2010 at 12:13 PM

I have found a problem with RmAttributeValue and RmResourceChanges, and to fix it I introduced a compatibility-breaking bug.

The point is that the GetDifference function of RmResourceChanges was treating everything as either an Add or a Remove operation,while one should use a Replace operation for single-valued attributes. It was then the resource factory that, knowing the schema, transformed Add and Remove changes to Replace. However, with a single valued attribute, this ended up creating two operations: an operation "Add new value" and an operation "Remove previous value", then transformed in two Replace operations.

In some cases this could cause an exception and make the operation fail.

I thought that the best thing to do was to treat differently single and multi valued attributes directly in the GetDifference function, but to do this I had to introduce a reliable way of determining if an RmAttributeValue is single or multivalued: the original mechanism of relying on the constructor called or on the values count was not appropriate - also note that "EnsureAttributeExist" in RmResource was creating everything as a single-valued attribute.

I ended up creating two new classes - RmAttributeValueSingle and RmAttributeValueMulti - but maybe there is a better alternative. I think we should decide this before making our first release.

Please let me know what you think about it.



Apr 10, 2010 at 6:10 PM

Hi Paolo,

Is this change stable in the current code?

I have the alternateEndpoint client, the stsEndpointClient, all the cruft required to exchange security tokens, and the passwordReset function implemented on the Default Client.

I am wondering if I should merge my changes with the current code or wait for you to finish working on the change you mention above.



Apr 12, 2010 at 9:07 AM

Hi Jeremy,

yes, the change is stable, but before we make a first release of the code, I'm open to other proposals. If you can suggest a way to handle this problem that does not break compatibility, please let me know.

Anyway, I think you can merge your code, then we shall see how to handle the different bits.