On Thu, May 04, 2017 at 10:34:38AM -0700, Han Zhou wrote: > On Thu, May 4, 2017 at 10:05 AM, Ben Pfaff <[email protected]> wrote: > > > > On Wed, May 03, 2017 at 11:43:15PM -0700, Han Zhou wrote: > > > On Wed, May 3, 2017 at 4:55 PM, Ben Pfaff <[email protected]> wrote: > > > > > > > > On Wed, May 03, 2017 at 07:42:46PM -0400, Russell Bryant wrote: > > > > > On Wed, May 3, 2017 at 11:45 AM, Ben Pfaff <[email protected]> wrote: > > > > > > It's much easier to see what's going on in the southbound > database if > > > > > > human-friendly names are available. > > > > > > > > > > > > Really it's too bad that we didn't put the human-friendly name in > > > "name" > > > > > > and the UUID in something like "external_ids:neutron-uuid", but > it'll > > > take > > > > > > Does OVSDB schema support index on map keys inside a column? > > > > No. For cases where the database needs to maintain uniqueness, a > > dedicated column is needed. But that is not always the case here. > > Yes, it doesn't matter for this patch. I just try to understand what should > be the desired design, if putting neutron-uuid in name was a bad idea. The > case in Neutron plugin (or maybe also in some other CMS systems) is that it > tries to avoid storing any ovn uuid's. When it needs to get corresponding > ovn object, it queries OVN NB by neutron-uuid. At least in > Logical_Switch_Port it seems nature to put it in "name" column, because in > the schema, name is unique index in Logical_Switch_Port, so just act as an > ID, although "name" suggests something else. If we put it in > external_ids:neutron-uuid, it is not indexable. Maybe it is not a big > problem because the "index" here in ovsdb may be not that critical as in > traditional db, because what matters is IDL cache, but still it seems not > right if some unique key can't be indexed. Another thing is, we have the > "name" in most of the OVN tables, some are index (e.g. the one in > Logical_Switch_Port), some are not. This may be confusing, too.
I agree that there are inconsistencies in the design. Some are easy to fix, some are not, and I think that we need to decided which are important enough to fix. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
