On Tue, 2014-11-25 at 09:20 +1100, Michael Still wrote: > - we do what we do in the current nova database -- we have a deleted > column, and we set it to true when we delete the instance.
Actually, current nova uses the oslo.db.sqlalchemy.models.SoftDeleteMixin class, which defines the columns 'deleted_at' (a DateTime) and 'deleted' (an *integer*). It also defines a 'soft_delete()' method, which sets the 'deleted' column to the row 'id'. As I understand it, this is to keep from breaking uniqueness constraints; you factor in 'deleted' in your uniqueness constraint, and you can have as many identical deleted records as you want… > - we have shadow tables and we move delete rows to a shadow table. > > - something else super clever I haven't thought of. Well, one thought might be to create a single 'audit' table with a couple of columns—a timestamp, say, and some sort of description of the change, perhaps as a JSON object. On a 'delete' operation, you could store the values of the row into this audit table. From an operator's standpoint, this could provide the required auditing and perhaps even a limited DR solution, while centralizing the data you need to monitor in a single location, which makes it easier to trim the data at intervals as needed. While I've proposed this as a soft-delete solution, it would also provide the ability to record other changes to objects; one could even include a column to record who performed the change. And of course I've suggested this as a DB table, but we could also consider the merits of ditching the table and doing the same thing as some sort of notification through the notifications system… -- Kevin L. Mitchell <kevin.mitch...@rackspace.com> Rackspace _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
