Merge lp://qastaging/~thisfred/desktopcouch/list-to-mergeable-list-mapping into lp://qastaging/desktopcouch

+1.

Tests pass, in spite of our best efforts with the debugger to break them. An apparent off-by-one error turned out not to be. Could we have a more comprehensive docstring to explain that the UUID associated with a given element may change if the order of the element values changes, even if the new element values are the same as the current ones apart from the order?

Code is good, tests pass.

We run the code through the debugger to understand the set_value method. At first we thought it was broken, but it is not, so good job. :-)

However, the docstring could stand some more verbosity. :-P

Here's how it could look:

"""
Set the value for the field, preserving the UUIDs as much as possible.

The value needs to be a sequence of elements.
If the field is not already present, it will be added and its value will be set
to a MergeableList containing the new elements.

If the field is already present, the current elements will be overwritten by
the new ones.

If the new elements are fewer than the current ones, the non-overwritten
current elements (the tail) will be dropped.

If the new elements are more than the current ones, the new ones in excess will
be appended to the list, and will get new UUIDs.
"""

Also, the APP_RECORD2 constant is not used (u1lint did not notice, weird). Its value should also be ['foo', 'bar'], to be in sync with TEST_RECORD2.

Thanks guys, all excellent points, will fix.

Nicola: pylint is (arguably) right about not complaining about unused constants: they are often imported by other modules. I will throw it out. I thought I was going to need both but I didn't. I did TDD this though :).

Also after further thought, I think we may want *another* slightly less simple mapping maybe, that does care about the values, so that it does not unintentionally stomp on changes from the backend.

Also because then we can correlate a list of simple values with a list of dictionaries more easily, which you'll now need to do by hand, but let's go with this for now, but use with care, i.e. try to get the values out of the record first, where applicable, and then do a sort of merge yourself, by looking at the values.