On Wed, Jun 11, 2008 at 12:40:05PM -0700, Jordan Brown wrote: > Nicolas Williams wrote: > >What would happen on upgrade? Which order would be assumed for existing > >multi-valued props? Or would those be flagged as unordered? I > >recommend the latter. > > I'm having a hard time seeing a requirement for unordered lists. If > you're expecting an unordered list and you happen to get an ordered one, > how could you care?
I think there are places where order is certainly irrelevant. Having a distinction might help set user expectations, but this is of rather low value. In any case, I thought the proposal was for adding a user/app-visible notion of whether any given protperty's value set is ordered. Whereas it seems instead to say that property value sets will always be ordered (except for pre-existing ones). > As a related matter, I don't think it matters what order existing > multi-valued properties get, since nothing could previously have > depended on it. Whatever that order is should probably be stable - an > existing previously unordered list should become an ordered list with > some unspecified order - but it doesn't matter what the order is. I'm not so sure. Though today property value sets are documented as unordered, the order produced is still deterministic, IIRC, with the current database used under the hood. So while nothing ought to depend on order, there may be things that do. > >Also, svccfg/svcprop/libscf would have to change too so that the > >set/sequence nature of a property could specified/observed. > > Do they? I could perhaps see a desire to add ways to insert, delete, > and replace values by index, but I don't immediately see why existing > interfaces would need to change. See my other reply just now.
