Mike Bayer wrote:
Precisely. Why is the RDBMS the thing that is used for archival/audit logging? 
Why not a NoSQL store or a centralized log facility? All that would be needed 
would be for us to standardize on the format of the archival record, 
standardize on the things to provide with the archival record (for instance 
system metadata, etc), and then write a simple module that would write an 
archival record to some backend data store.

Then we could rid ourselves of the awfulness of the shadow tables and all of 
the read_deleted=yes crap.

+1000 - if we’re really looking to “do this right”, as the original message 
suggested, this would be “right”.  If you don’t need these rows in the app (and 
it would be very nice if you didn’t), dump it out to an archive file / 
non-relational datastore.   As mentioned elsewhere, this is entirely acceptable 
for organizations that are “obliged” to store records for auditing purposes.   
Nova even already has a dictionary format for everything set up with nova 
objects, so dumping these dictionaries out as JSON would be the way to go.

+ 1001; dump it out to some data warehouse, put it to HDFS, do something else with long term storage IMHO; just let's avoid continuing to turn a database into a data warehouse, they are really not the same thing and don't have the same requirements, constraints ...

I've always been confused why some of the openstack tables tried to do both roles with a deleted=1|0 field. The part that has also been confusing to me is has anyone actually tried switching a deleted=1 field back to deleted=0 without application logic to do this; if so how did u manage to pull that off correctly without knowing the inner details of the application itself (how did u do this atomically so that the users *actively* running against the api would not start to receive weird responses and failures...)?

OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to