On Fri, Apr 21, 2017 at 5:21 AM, Don Zickus <dzic...@redhat.com> wrote: > Then as a follow-on, we are assuming the database has to be updated to add > this entry, would it make sense to convert the whole database to a generic > key/value table to dynamically support new fields without having to migrate > the whole database all the time? And then to prevent random junk from being > added by the inventory script (or other script), have a whitelist filter > that only allows certain keys to be added/updated. Maintaining the > whitelist would be easier on the database then adding table entries.
Beaker used to have a generic key-value store as a MySQL table, but it caused all sorts of performance problems on the display and filtering side of things, so it wouldn't be a good idea to go back down that specific road. That said, things have also moved on significantly on the data storage side of things since then, with "Dynamic Columns" in MariaDB 10+, and support for hstore and JSON columns in PostgreSQL. That means there should be options available that allow the inventory system to move back to a schemaless storage model without encountering the same kinds of problems it did historically, and without requiring the addition of a completely separate document store to all Beaker deployments. Cheers, Nick. -- Nick Coghlan Red Hat Platform Engineering, Brisbane _______________________________________________ Beaker-devel mailing list -- beaker-devel@lists.fedorahosted.org To unsubscribe send an email to beaker-devel-le...@lists.fedorahosted.org
