On Fri, Apr 21, 2017 at 5:21 AM, Don Zickus <dzickus(a)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