On Sep 20, 2006, at 7:21 PM, John Siracusa wrote:
> 1. Override load() in your common base class and check is_deleted()
> before
> 2. Override get_objects() in a custom Manager subclass and then
> base all
good ideas. I'll give that a shot
> straightforward and predictable. (What if I *w
On 9/20/06 1:55 PM, Christopher Masto wrote:
> Jonathan Vanasco wrote:
>> as an example, in a system i have, no deletes are immediate, deletes
>> are just bool flags + a deletion queue entry / timestemp, that waits
>> for a month before actual deletion.
>> so 95% of my selects on the public side in
On Sep 20, 2006, at 2:50 PM, Randal L. Schwartz wrote:
> I handled that in a client app by defining a "view" that doesn't show
> me the deleted items. Maybe you can do the same, unless you're using
> a broken database that doesn't support views. :)
No, I'm using pg, not that other thing.
I jus
> "Jonathan" == Jonathan Vanasco <[EMAIL PROTECTED]> writes:
Jonathan> i thought of it, because i use boolean flags to handle a lot of
Jonathan> public facing things on my system.
Jonathan> as an example, in a system i have, no deletes are immediate, deletes
Jonathan> are just bool flags
Jonathan Vanasco wrote:
> as an example, in a system i have, no deletes are immediate, deletes
> are just bool flags + a deletion queue entry / timestemp, that waits
> for a month before actual deletion.
> so 95% of my selects on the public side include 'is_deleted= FALSE"
I tend to have thing
Many of you may scoff at this, but it just popped into my head, and
seems nifty , so I thought I'd share.
What if there were a
__PACKAGE__->meta->default_where
that held certain attributes that should be incorporated into all
selects, either through the load() or manager get() or wit
