Morning Guys,

@ Nando, thanks for your suggestions, I'll have to do some prototyping
with this kind of model and see how things shape up, I just want to
avoid any excess code for it but maybe a nice solution can be rolled
together :-)

@Mark, yeah I saw in the notes that the cache was your main obstacle,
I've not really used the cache very extensively so don't really have
any suggestions as to how that one can be solved, I mean, when you say
'Where it all gets tricky is if you want to pull back the object in
after being deleted' what do you mean by this, are we actually
changing the state of the object from deleted to live again? or we
just want to retrieve the deleted objects? I mean, perhaps 'deleted'
is the wrong term here, perhaps we should be calling them 'archived'
objects or something.

Can objects not just be loaded back into the cache in the same way as
a new object being created?

I also see that you talk about the fact that we'd still have to
include the filter options in the TQL to save it pulling deleted
objects from the DB, this is no real biggy but again it all detracts
from the idea of the ORM having it as a native feature, The
implementation from my point of view would in an ideal world be
seamless, I'd query and delete objects in the same fashion as I do now
but Transfer would handle the rest, if I've still got to concern
myself with asking the ORM not to pull deleted records then I might as
well go to the effort of overwriting the delete methods with update
myself and not have the feature in the ORM?

With that said; there are always situations where I DO want to pull
deleted objects, this should be specifiable in the TQL and override
the default setting of it not pulling deleted records, you almost need
to make 'achived' or 'deleted' a nonsettable property on the object
which is controlled solely by the ORM, then in my TQL is assumes I
only ever want objects Achived = False but if needs be I can specify
Archived = True and get my hands on them.

Another quickie; with regards to the conditions on the collections,
how does that work? this involves CF doing the leg work of not giving
back the deleted records, correct? My only concern with that would be
that in busy application where we have high-turnover of objects the
number of deleted records becomes by quite a stretch the more dominant
count of objects and yet they're seldom used by the end user and it
seems a shame to be eating up all my cache space and have CF chug
through the collection all the time when really the deleted records
should be sat in the DB until they're required.

This is a good discussion guys, thanks a great deal for all the
suggestions that are flying around :-) Apologies if I'm a little slow
on the uptake for some of them, I've been working ORM free for the
past few months ;-)

Rob

On Mar 3, 9:54 pm, Matt Williams <[email protected]> wrote:
> On Mar 3, 4:06 pm, Mark Mandel <[email protected]> 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 [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/transfer-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to