David Bustos wrote: > >> The subject of the ordering of property values has come >> up here a few times before, for example see: >> >> http://www.opensolaris.org/jive/thread.jspa?messageID=53690톺 >> > > So what is your take on Stephen's network repository issue? I wonder if > we could add a piece of metadata to properties which specify whether > they're ordered or unordered. By default they'd be ordered, but if an > application doesn't care then it can make them unordered, which would > free svc.configd to avoid emulating order in an unordered backend. Or > maybe the ordering should be a flag on the retrieval interface. Or > maybe the current retrieval interfaces should be designated "ordered", > and we can add separate unordered retrieval interfaces. If we wanted to > do this, we could probably put it off actual unordered properties until > we have a network backend, and make any interface changes as > opportunities arise. > > Nice summary of the options. Defaulting to ordered storage/retrieval would be my preference here, with possible future changes based on explicit requirements for unordered value support. I'm not quite sure what constraints the network repository requirements would impose - what do you think Stephen?
>> To support ordering at the repository level, I suggest >> adding an additional column to the value_tbl, named >> value_order. When we add property values, we would >> need to also specify ordering (0, 1, 2, ..) for this column. >> On retrieval then, we can modify the backend SELECT >> statement to ORDER BY the value_order column and >> thus ordering is preserved. >> > > Sounds good. > > >> A major concern with such a change of course is >> handling upgrade to a new repository format, while >> also supporting downgrade from the new format to the >> previous format. To ensure svc.configd can deal >> with the repository format, the repository carries a >> schema version number which must match the version >> encoded in svc.configd in order for the repository >> to be usable. My suggestion is that we do not bump >> this version number for this change. A downgraded >> svc.configd can actually handle a repository with the >> extra value_order column perfectly (it merely ignores it). >> It might make sense introduce a minor version number into >> the schema_version table, to reflect that the schema >> has changed, but not in an incompatible manner. >> > > Is supporting downgrade a hard requirement? > > If we explicitly bumped the version number - and thus needed to do an explicit downgrade - we could add logic to bfu etc to remove the value_order column (this could be done using /lib/svc/bin/sqlite). In testing, it does seem like earlier configd versions can handle a repository with the additional value_order column, but it seems a bit hacky not to register the fact that the repository is upgraded just to make downgrade easier (adding a minor version to the schema_version table might be enough though). >> This leaves the issue of upgrading to the new >> repository format. Ideally, we would like to >> add the new column as soon as the repository >> is writable on upgrade, but we have to deal >> with a few complications: >> >> - during boot, we need to read property values prior to the >> point when we can do the repository upgrade (i.e. prior to >> the repository being writable) >> - the version of sqlite used does not support the ADD COLUMN >> command, so adding a new column to the value_tbl >> is not straightforward. >> >> To address the first issue, we need to keep track of >> whether upgrade has been carried out for a particular >> backend. This is important, because during first boot >> post-upgrade, we will need to read values before >> we can write to (and upgrade) the repository. This >> means we need to modify the SELECT statement >> that retrieves values based on whether the upgrade >> has been done (since prior to upgrade it cannot use >> the ORDER BY value_order clause in the SELECT >> statement that retrieves values). >> > > True. We should be able to assume that the nonpersistent repository is > in the new format, though, shouldn't we? Unless I suppose we want to > support changing the svc.configd binary without rebooting. > > Hmm, perhaps the latter scenario may be required for "pkg upgrade" (though I believe by default it upgrades the inactive BE). > Did you happen to determine when ADD COLUMN was added? If was before > 3.0, upgrading might be an option. > > Looks like it was version 3.2.0 unfortunately (see http://sqlite.org/changes.html). Thanks! Alan
