Michael Shapiro writes: > > > On Mon, Aug 28, 2006 at 02:20:49PM -0700, Michael Shapiro wrote: > > > > On Sun, Aug 27, 2006 at 01:55:33PM -0700, Alan Maguire wrote: > > > > > quick question about multivalued properties that are order-dependent > > > > > (in this case the property represents an option to a daemon that can > > > > > appear multiple times on the commandline). > > > > > > > > > > given that smf does not guarantee order being preserved for property > > > > > values, is the right thing to do to use a single astring value and a > > > > > separator > > > > > between each value in the string? > > > > > > > > Yes, that's exactly what you should do. > > > > > > > > Dave > > > > > > In terms of the command-line options thing that may be the right thing to > > > do but I think the more general case is entirely broken. We *should* > > > support order-dependent properties, otherwise typed multi-valued > > > properties > > > are completely useless for a large category of problems. > > > > I agree. > > > > > The only reason it doesn't work is a stupid bug in scf_entry_add_value() > > > wherein the code (to make its own life easier) adds new things to the > > > head of a linked list to avoid keeping a tail pointer. > > > > Actually, the interface wasn't derived from the implementation here. > > It has long been part of the design that all collections be unordered > > to "reduce the network repository requirements dramatically". > > > > I didn't make this decision, and don't know if the rationale still > > holds. I do know that it isn't just a bug in libscf. > > > > > As a result, > > > every multi-valued property ends up in the exact reverse order in which > > > items were added. I was planning on fixing this and updating the docs. > > > > That addresses the libscf half. You also need to verify that the > > repository format and protocol are designed to preserve ordering. > > > > Dave > > 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 -- in particular it makes > the use of multi-value network address properties nearly useless.
I've only looked briefly at how configd interfaces with the underlying database manager, which is SQLite. So at this stage of the game, I don't have detailed knowledge about the schema or the SQL queries. Nonetheless, it seems to me that one question is whether or not the DBM will preserve the ordering of the values? Looking to the future, if we decide to switch out SQLite for some other DBM, will it preserve the same ordering? I know that we could fix that by adding an ordering value to the tuple, but I don't think it is there now. > > -Mike > > -- > Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org
