On Fri, Apr 20, 2012 at 10:40:20AM -0400, Scott Seago wrote:
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_to_keep_a_history_of_deployment_activity
>>
>>
>> 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.
If we don't intend to allow people to un-delete records, I think we
could make it work pretty easily with something like this:
validates_uniqueness_of :name, :unless => deleted_at
That does imply that you couldn't have a unique constraint in the
database on :name, but I think that's an inevitable cost of doing this.
(Though you could kind of hack it with a compound key, but it would be
ugly and bad.)
-- Matt