> * Michael Shapiro <mws at zion.eng.sun.com> [2006-08-28 15:49]: > > I've confirmed that fixing scf_entry_add_value() fixes the problem, insofar > > as I can tell by executing experiments. Jonathan, is there some more subtle > > issue inside the repository I should be aware of? I don't recall this > > decision, but as I say above it makes no sense -- > > Umm, it's actually quite sensible, if you think about how to support > multi-valued properties in the network name service implementations > currently in use. Ordered responses are not generally supported by > these protocols--forcing the scf_* interfaces to order responses means > one or more tradeoffs in the network repository representation, which > I was not prepared to make at the time. > > Tradeoffs that I worked through were: addition of an ordering column > in each row (insertion becomes an ID renumbering series of > operations), versus pickling multiple values into a single row (bounded > by network repository maximum row length) or multiple rows (reduces > bound, but reintroduces renumbering and chunk management). > > I'm happy to discuss which of these we pursue, but I would like this > choice to be made before changing the behaviour. It doesn't look like > the behaviour made it into the reference documentation (although it is > in the architecture document), so the impact on current practice > should be minimal. We can then actually document the ordered > behaviour... > > > in particular it makes the use of multi-value network address > > properties nearly useless. > > - Stephen
The only sane behavior is that ordering of the values of a multi-valued property be preserved. And given the current APIs we've committed to, that ordering should be the order of scf_entry_add_value() when building a transaction. I would still like to hear whether the current database backend for the local case supports that as I've experimentally determined that it does or whether there is some more subtle issue lurking. I'd like to get this fixed and documented soon. For the reasons of sane design, I think adhering to this behavior needs to be a requirement for the networked repository. I don't see how it overly constrains the world because if the networked repository can provide single-value retrieval then we can implement value packing/unpacking in an ordered fashion on top of that if native backend support for ordering isn't available from a particular backend. In any case, given that there isn't a networked repository yet let's please agree on the end state such that the local thing can be fixed and the docs corrected and then go work on the network repository issues. The present state is just completely broken. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
