On Thu, Mar 13, 2014 at 12:42 PM, Boris Pavlovic <[email protected]>wrote:
> Hi stackers, > > As a result of discussion: > [openstack-dev] [all][db][performance] Proposal: Get rid of soft deletion > (step by step) > http://osdir.com/ml/openstack-dev/2014-03/msg00947.html > > I understood that there should be another proposal. About how we should > implement Restorable & Delayed Deletion of OpenStack Resource in common way > & without these hacks with soft deletion in DB. It is actually very > simple, take a look at this document: > > > https://docs.google.com/document/d/1WGrIgMtWJqPDyT6PkPeZhNpej2Q9Mwimula8S8lYGV4/edit?usp=sharing > > > Best regards, > Boris Pavlovic > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > Hi Boris, Before I voice a little disagreement, I'd like to thank you for kicking off this discussion and stress that I strongly agree with your view (pulled from the other thread) > To put in a nutshell: Restoring Delete resources / Delayed Deletion != Soft deletion. This is absolutely correct and the key to unlocking the problem we have. However, because of migrations and because being explicit is better than being implicit, I disagree about the idea of lumping deleted resources all into the same table. For glance, I'd much rather have a table "deleted_images" than a table "deleted_resources" that has some image entries. There are a number of reasons, I'll try to give a quick high-level view of them. 1) Migrations for deleted data are more straightforward and more obviously necessary. 2) It is possible to make specific modifications to the "deleted_X" schema. 3) It is possible to take many tables that are used to represent a single active resource (images, image_locations, image_tags, image_properties) and combine them into a single table for a deleted resource. This is actually super important as today we have the problem of not always knowing what image_properties were actually deleted prior to the image deletion vs the ones that were deleted as a part of the image deletion. 4) It makes it a conscious choice to decide to have certain types of resources restorable or have delayed deletes. As you said before, many types of resources just don't need this functionality, so let's not make it a feature of the common base class. (I am assuming for #2 and #3 that this common approach would be implemented something like "deleted_resource['data'] = json.dumps(dict(active_resource))", sorry if that is seriously incorrect.) Thanks for your consideration, markwash
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
