On 2012-03-09, at 7:52 AM, Jay Pipes wrote: >> The data is stored in a python dictionary, inside of the metadata table. >> You will not be able to use SQL without an unwieldy wildcard search. IMO >> this seems overly complicated for a core function of the tool, and possibly >> the reason why listing user/tenant roles hasn't been implemented. > > ++ > > I suspect the existing SQL schema has more to do with the default of using a > key-value store until recently. > > I think that storing in the roles relationships in the "extra" column is a > bit of premature optimization that is a little ill-conceived at this point -- > it sacrifices functionality for a perceived performance improvement. I don't > believe there's any evidence that the join to a roles table (or two joins for > a mapping many-to-many relationship table) had an adverse impact on > performance in the legacy Keystone. > > -jay
++ Storing data in a non-relational way when it is useful to access it in a relational way is doubleplusungood. If a cache in the "extra" column is needed for performance it can always be maintained in addition to a table with transactional updates. Thanks, Maru _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
