----- Original Message -----
From: "Scott Seago" sseago@redhat.com To: aeolus-devel@lists.fedorahosted.org Sent: Friday, April 20, 2012 10:40:20 AM Subject: Re: RFC Feature Planning: Deployment Activity History
On 04/20/2012 04:17 AM, Jan Provazník wrote:
On 03/30/2012 05:59 PM, Tzu-Mainn Chen wrote:
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Allow_Conductor_t...
The document talks about two possible approaches to keeping deployment activity; one is to use an archive table, and another is to use a soft_delete flag. I'd be interested in hearing people's thoughts on both.
Oh, and the document also talks about potentially using dbomatic for periodic history purges. I know there's been some discussion around dbomatic, so if someone had an opinion about that as well. . .
Mainn
Hi Mainn, one nit which wasn't probably mentioned (or I missed it) is potential problem with unique keys:
- primary keys - I think we use everywhere 'id' so it shouldn't be
problem (as long as we don't use for example 'name' as primary key)
- 'validates_uniqueness_of' for all models which use soft deletion
will have to be updated (acts_as_paranoid doesn't re-implement this method)
Jan
Jan, yes I'd forgotten entirely about that. Unique fields and deleted items were a big problem last time I worked with an in-house-designed soft-delete model. We ended up having to mangle names, etc. as part of the 'delete' action. You could get around this by hacking validates_uniqueness_of, but that's probably really painful. In addition, that won't work if you ever have a uniqueness constraint on the underlying db table, or if you have other custom validation methods that also have a problem with uniqueness.
Scott
Actually, there seems to be a pretty simple solution:
validates_uniqueness_of :name, :scope => [:pool_id, :deleted_at]
Mainn