On Wed, Mar 16, 2011 at 12:59, C. Michael Pilato <cmpil...@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. Cheers, -g
