On Wed, Mar 16, 2011 at 12:59, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> to manage at least the "read" subset of these operations. But I find myself
> wondering if we wouldn't be better served by having a properties table with
> rows for, I dunno: wc_id, local_relpath, property_name, property_value.
> Was this considered when we moved the properties into the database? If so,
> why didn't we take this approach? Should we consider it now? Should we
> punt it to 1.8?
It was considered. Hyrum and I figured it would be best to use a skel
and avoid a join. We assumed it is the rare case that we need a single
property, rather than some/all of the properties.
If you want to experiment with another table and a JOIN, then I would
recommend waiting until 1.8 to do that. If we find that properties in
their current form are killing us, then we can discuss further.
My understanding is that # queries is our concern at the moment,
rather than skel-unpacking.
Received on 2011-03-16 18:18:01 CET