On Mar 3, 4:06 pm, Mark Mandel <mark.man...@gmail.com> wrote:
> All good stuff guys.
>
> Another option - for basic soft deleting, set up conditions on your
> collections, to ignore your soft deleted items.
>
> Then when soft deleting, if you do an update(), do a discard() after,
> which will clear out the object from collections.
>
> You will still need to filter when doing TQL operations, but it gets
> you 99% of the way there.
>
> Where it all gets tricky is if you want to pull back the object in
> after being deleted - the cache pretty much gets in the way, which can
> be tricky (that's the real fun one.. how do you manage the cache when
> people want to undelete).
>
> Mark
>
This is essentially how I handle it. And I have to add "deleted
= :deleted" for any parent, child or sibling tables. I use true or
false instead of nulls, so there is a corresponding setParam
('deleted','false','boolean') along with each query. And in the case
of an OUTER JOIN, I will have (deleted = :deleted OR deleted IS NULL)
I'm not sure if I'll have to worry about the undelete challenge or
not. I suppose one option would be to somehow force a reload of all
those related objects.
Matt Williams
--~--~---------~--~----~------------~-------~--~----~
Before posting questions to the group please read:
http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer
You received this message because you are subscribed to the Google Groups
"transfer-dev" group.
To post to this group, send email to transfer-dev@googlegroups.com
To unsubscribe from this group, send email to
transfer-dev-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/transfer-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
