On 17/03/2010, at 8:14 AM, Xavier Shay wrote: > the data has very different profiles - unconfirmed orders are pretty much > transient/throw away, where as a confirmed order needs to stick around. > > This becomes *especially* relevant when you start getting more than one > 'confirmed_at' type column on your tables. > > small, elegant, focused tables. The same way we design models. > > Rule of thumb - if a column very rarely needs to be NULLable.
I'm a long-time user of is_paranoid, but I'm really coming round to this idea. There are a lot of corner cases with the deleted_at approach involving associations, that require CONSTANT VIGILANCE to avoid. One good example: you have a table with an associated join table, both of which are paranoid. You have a few joins, delete some of them, and then delete the main record. If you don't cascade the soft-delete to the joins, then they'll show up when you query that table. But if you do delete them, how do you know which joins to undelete when you undelete the main record? That is, which were deleted of their own accord, and which through a cascade? (I wrote an is_paranoid patch that uses the same precise timestamp when cascading deletes, and then matching it on undelete, but that's more complexity than I want around something as fundamental as whether something "exists" or not.) On 17/03/2010, at 8:14 AM, Xavier Shay wrote: > don't need to remember to scope anything, harder to screw things up (like > shipping an unconfirmed order, or presenting a report to the boss containing > unconfirmed orders) I like this reasoning as well. Best of both worlds—with the deleted_at example, proper undeletion is still possible, but you know for a fact that your actual table only contains active records. I think I'll be using the separate table approach in future :) —ben_h -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-ocea...@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
