Open Stack

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.mitchell at rackspace.com>
Rackspace