[transfer-dev] Re: Soft Delete?
Hey Mark, Thanks for the thorough reply mate, that certainly does make sense, I can see the difficulties that it presents. The reason this didn't spring to mind with me at first was that the deleted objects for me wouldn't generally be retrieved through transfer into a collection, they're generally pulled for auditing and reporting data which is all done using complex SQL equations doing all kinds of fancy math for me and generally the object itself wouldn't be pulled back in. I'll figure something out ad-hock for now, this certainly seems like a much more complicated task than it would first appear :-) Rob On Mar 4, 7:34 pm, Mark Mandel wrote: > > @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. > > Doesn't really matter what you call them - the issue is the cache and > the compositions that object is involved in. > > a) if something is in the cache, it is deemed persisted. Regardless of > whether or not you use real, or soft delete, that is pretty much the > case. > b) If you return an object back to 'persisted' state, after being > deleted, you will need to notify any composition it COULD have been in > - hey, you may need to add this object. This is tricky (not > impossible, just tricky). > c) If you just want to retrieve the deleted object, and look at it - > you have to make sure IT's compositions work in the cache, but that > those of live objects don't... or maybe the deleted object doesn't get > cached, but we need to make sure that doesn't corrupt the live > cache... > > > > > Can objects not just be loaded back into the cache in the same way as > > a new object being created? > > Again, it's an issue of composition. > > > > > 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? > > Yeah, that is why it would be nice if Transfer handled it natively. > > > > > > > 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. > > Not sure what you mean by 'how does this work'? You mean conditions in > general > -http://docs.transfer-orm.com/wiki/Transfer_Configuration_File.cfm#one... > has some documentation on it. > > > > > 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 > >-- > > E: mark.man...@gmail.com > W:www.compoundtheory.com --~--~-~--~~~---~--~~ 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,
[transfer-dev] Re: Soft Delete?
> @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. Doesn't really matter what you call them - the issue is the cache and the compositions that object is involved in. a) if something is in the cache, it is deemed persisted. Regardless of whether or not you use real, or soft delete, that is pretty much the case. b) If you return an object back to 'persisted' state, after being deleted, you will need to notify any composition it COULD have been in - hey, you may need to add this object. This is tricky (not impossible, just tricky). c) If you just want to retrieve the deleted object, and look at it - you have to make sure IT's compositions work in the cache, but that those of live objects don't... or maybe the deleted object doesn't get cached, but we need to make sure that doesn't corrupt the live cache... > > Can objects not just be loaded back into the cache in the same way as > a new object being created? Again, it's an issue of composition. > > 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? Yeah, that is why it would be nice if Transfer handled it natively. > > 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. Not sure what you mean by 'how does this work'? You mean conditions in general - http://docs.transfer-orm.com/wiki/Transfer_Configuration_File.cfm#onetomany has some documentation on it. > > 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 >-- E: mark.man...@gmail.com W: www.compoundtheory.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[transfer-dev] Re: Soft Delete?
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 wrote:
> On Mar 3, 4:06 pm, Mark Mandel 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
-~--~~~~--~~--~--~---
[transfer-dev] Re: Soft Delete?
On Mar 3, 4:06 pm, Mark Mandel 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
-~--~~~~--~~--~--~---
[transfer-dev] Re: Soft Delete?
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
On Wed, Mar 4, 2009 at 6:45 AM, Nando wrote:
> Rob,
>
> Perhaps I misunderstand your line of questioning? I'm not sure. Again, the
> obvious answer to me would be a JOIN with the appropriate WHERE clauses,
> which may mean that both the parent and child would need to be specified,
> depending on your JOIN. Hmmm?
>
> I can't see how we might expect TQL or Transfer in general to evolve to the
> point where it would be aware of what I'll term "soft delete cascade
> relationships" or even "delete cascade relationships" as separate from the
> relationships defined in Transfer.xml, and while we are at it, "save cascade
> relationships" ... and then yes, conditional forms of all of those
> additional relationship definitions might also be useful! Doesn't seem
> practical to me, but this is all way over my head, so I should just stop
> here. ;-)
>
> On Tue, Mar 3, 2009 at 6:32 PM, Sir Rawlins
> wrote:
>>
>> Nando thanks,
>>
>> I get the whole 'where' clause situation, however how does that react
>> when it comes to composed objects? So, I pull my parent object like
>> so:
>>
>> FROM SomeParantObject AS
>> SomeParentObject
>> WHERE
>> SomeParentObject.DeletedOn IS NULL
>>
>> Now, what about all the parent children who need to be filtered? I
>> dont want it populated with 'deleted' children do I? am I able to do
>> that with the TQL?
>>
>> Thanks,
>>
>> Rob
>>
>> On Mar 3, 5:23 pm, Nando wrote:
>> > As you probably know, cascadeDelete() in Transfer "goes everywhere" in
>> > the object graph defined, so especially in the case of deletes, you
>> > probably need to manage how you want it to cascade on a case by case
>> > basis. At least I often always do.
>> >
>> > As to your SELECT statements, you simply need WHERE clauses that
>> > exclude them when needed. I don't think there is a simple way around
>> > that, at least not to my knowledge.
>> >
>> > On Tue, Mar 3, 2009 at 5:57 PM, Sir Rawlins
>> >
>> >
>> >
>> - Show quoted text -
>> > wrote:
>> >
>> > > Wow chaps, a million and one options to choose from eh? great stuff!
>> >
>> > > @Sean, that's not a half bad idea, I've just always found that in the
>> > > past having things like that split across different resources just
>> > > ends up being a nightmare, its much the same reason I stopped using
>> > > Stored Procs, it just becomes a nightmare trying to maintain things,
>> > > whereas if they're all inside my nice warm codebase then I know where
>> > > to fix issues when they arise ;-)
>> >
>> > > @ Nando, Brian, that concept certainly seems very attractive, using
>> > > the decorator to do the work, two things jump to mind with this
>> > > though:
>> >
>> > > 1. cascade deletes, presumably calling ParentObject.delete() will
>> > > invoke my nice soft delete method on the parent, would this in turn be
>> > > able to invoke the children soft deletes? and
>> >
>> > > 2. Select statements, how could I have both the transfer built in get
>> > > ('someobject', someobject_id) methods and my TQL select methods ignore
>> > > the deleted objects? we also need to bare in mind that in some
>> > > instance, when working with Audit data I will want to pull the deleted
>> > > objects, sometimes I wont.
>> >
>> > > Cheers for the discussion guys, I appreciate the advice, I just want
>> > > something code-minimal, after all its got to be worth the hassle of
>> > > moving over.
>> >
>> > > Thanks,
>> >
>> > > Rob
>> >
>> > > On Mar 3, 4:30 pm, Brian Kotek wrote:
>> > >> That's exactly how I do this. I'm not a huge fan of ActiveRecord or
>> > >> patterns
>> > >> where objects know how to save themselves, but I've found that the
>> > >> flexibility outweighs the cons. If you have a generic delete() method
>> > >> in
>> > >> your base Decorator, then you can extend it with a
>> > >> SoftDeleteAwareDecorator,
>> > >> which overrides the delete() method and instead does a save() and
>> > >> updates
>> > >> the deleted flag instead of deleting it. Then any concrete Decorators
>> > >> extend
>> > >> the soft delete Decorator, and nothing external has to know whether
>> > >> the
>> > >> record is actually deleted or soft deleted.
>> >
>> > >> On Tue, Mar 3, 2009 at 11:23 AM, Nando wrote:
>> >
>> > >> > Rob,
>> >
>> > >> > I use soft deletes all the time in Transfer. In essence, it's
>> > >> > simply
>> > >> >
[transfer-dev] Re: Soft Delete?
Rob,
Perhaps I misunderstand your line of questioning? I'm not sure. Again, the
obvious answer to me would be a JOIN with the appropriate WHERE clauses,
which may mean that both the parent and child would need to be specified,
depending on your JOIN. Hmmm?
I can't see how we might expect TQL or Transfer in general to evolve to the
point where it would be aware of what I'll term "soft delete cascade
relationships" or even "delete cascade relationships" as separate from the
relationships defined in Transfer.xml, and while we are at it, "save cascade
relationships" ... and then yes, conditional forms of all of those
additional relationship definitions might also be useful! Doesn't seem
practical to me, but this is all way over my head, so I should just stop
here. ;-)
On Tue, Mar 3, 2009 at 6:32 PM, Sir Rawlins <
robert.rawl...@thinkbluemedia.co.uk> wrote:
>
> Nando thanks,
>
> I get the whole 'where' clause situation, however how does that react
> when it comes to composed objects? So, I pull my parent object like
> so:
>
>FROMSomeParantObject AS
> SomeParentObject
>WHERE
> SomeParentObject.DeletedOn IS NULL
>
> Now, what about all the parent children who need to be filtered? I
> dont want it populated with 'deleted' children do I? am I able to do
> that with the TQL?
>
> Thanks,
>
> Rob
>
> On Mar 3, 5:23 pm, Nando wrote:
> > As you probably know, cascadeDelete() in Transfer "goes everywhere" in
> > the object graph defined, so especially in the case of deletes, you
> > probably need to manage how you want it to cascade on a case by case
> > basis. At least I often always do.
> >
> > As to your SELECT statements, you simply need WHERE clauses that
> > exclude them when needed. I don't think there is a simple way around
> > that, at least not to my knowledge.
> >
> > On Tue, Mar 3, 2009 at 5:57 PM, Sir Rawlins
> >
> >
> >
> - Show quoted text -
> > wrote:
> >
> > > Wow chaps, a million and one options to choose from eh? great stuff!
> >
> > > @Sean, that's not a half bad idea, I've just always found that in the
> > > past having things like that split across different resources just
> > > ends up being a nightmare, its much the same reason I stopped using
> > > Stored Procs, it just becomes a nightmare trying to maintain things,
> > > whereas if they're all inside my nice warm codebase then I know where
> > > to fix issues when they arise ;-)
> >
> > > @ Nando, Brian, that concept certainly seems very attractive, using
> > > the decorator to do the work, two things jump to mind with this
> > > though:
> >
> > > 1. cascade deletes, presumably calling ParentObject.delete() will
> > > invoke my nice soft delete method on the parent, would this in turn be
> > > able to invoke the children soft deletes? and
> >
> > > 2. Select statements, how could I have both the transfer built in get
> > > ('someobject', someobject_id) methods and my TQL select methods ignore
> > > the deleted objects? we also need to bare in mind that in some
> > > instance, when working with Audit data I will want to pull the deleted
> > > objects, sometimes I wont.
> >
> > > Cheers for the discussion guys, I appreciate the advice, I just want
> > > something code-minimal, after all its got to be worth the hassle of
> > > moving over.
> >
> > > Thanks,
> >
> > > Rob
> >
> > > On Mar 3, 4:30 pm, Brian Kotek wrote:
> > >> That's exactly how I do this. I'm not a huge fan of ActiveRecord or
> patterns
> > >> where objects know how to save themselves, but I've found that the
> > >> flexibility outweighs the cons. If you have a generic delete() method
> in
> > >> your base Decorator, then you can extend it with a
> SoftDeleteAwareDecorator,
> > >> which overrides the delete() method and instead does a save() and
> updates
> > >> the deleted flag instead of deleting it. Then any concrete Decorators
> extend
> > >> the soft delete Decorator, and nothing external has to know whether
> the
> > >> record is actually deleted or soft deleted.
> >
> > >> On Tue, Mar 3, 2009 at 11:23 AM, Nando wrote:
> >
> > >> > Rob,
> >
> > >> > I use soft deletes all the time in Transfer. In essence, it's simply
> > >> > an update to a particular column.
> >
> > >> > My understanding from what Mark has said in the past is that because
> > >> > everyone does soft deletes in a different way, in fact your way,
> > >> > involving a date field, is different from mine, so it's somewhat
> > >> > difficult to implement in Transfer in a way that would work well for
> > >> > everyone.
> >
> > >> > I know Brian Kotek is a big fan of injecting transfer into his
> > >> > decorators, precisely into an abstract decorator, wrapping transfer
> > >> > methods to enable stuff like myObject.save(). If you adopted that
> > >> > approach, you could overwrite the abstract decorator on the concrete
> > >> > to enable your approach to soft deletes, even a varying approach as
> > >> > you've describ
[transfer-dev] Re: Soft Delete?
Nando thanks,
I get the whole 'where' clause situation, however how does that react
when it comes to composed objects? So, I pull my parent object like
so:
FROMSomeParantObject AS
SomeParentObject
WHERE
SomeParentObject.DeletedOn IS NULL
Now, what about all the parent children who need to be filtered? I
dont want it populated with 'deleted' children do I? am I able to do
that with the TQL?
Thanks,
Rob
On Mar 3, 5:23 pm, Nando wrote:
> As you probably know, cascadeDelete() in Transfer "goes everywhere" in
> the object graph defined, so especially in the case of deletes, you
> probably need to manage how you want it to cascade on a case by case
> basis. At least I often always do.
>
> As to your SELECT statements, you simply need WHERE clauses that
> exclude them when needed. I don't think there is a simple way around
> that, at least not to my knowledge.
>
> On Tue, Mar 3, 2009 at 5:57 PM, Sir Rawlins
>
>
>
> wrote:
>
> > Wow chaps, a million and one options to choose from eh? great stuff!
>
> > @Sean, that's not a half bad idea, I've just always found that in the
> > past having things like that split across different resources just
> > ends up being a nightmare, its much the same reason I stopped using
> > Stored Procs, it just becomes a nightmare trying to maintain things,
> > whereas if they're all inside my nice warm codebase then I know where
> > to fix issues when they arise ;-)
>
> > @ Nando, Brian, that concept certainly seems very attractive, using
> > the decorator to do the work, two things jump to mind with this
> > though:
>
> > 1. cascade deletes, presumably calling ParentObject.delete() will
> > invoke my nice soft delete method on the parent, would this in turn be
> > able to invoke the children soft deletes? and
>
> > 2. Select statements, how could I have both the transfer built in get
> > ('someobject', someobject_id) methods and my TQL select methods ignore
> > the deleted objects? we also need to bare in mind that in some
> > instance, when working with Audit data I will want to pull the deleted
> > objects, sometimes I wont.
>
> > Cheers for the discussion guys, I appreciate the advice, I just want
> > something code-minimal, after all its got to be worth the hassle of
> > moving over.
>
> > Thanks,
>
> > Rob
>
> > On Mar 3, 4:30 pm, Brian Kotek wrote:
> >> That's exactly how I do this. I'm not a huge fan of ActiveRecord or
> >> patterns
> >> where objects know how to save themselves, but I've found that the
> >> flexibility outweighs the cons. If you have a generic delete() method in
> >> your base Decorator, then you can extend it with a
> >> SoftDeleteAwareDecorator,
> >> which overrides the delete() method and instead does a save() and updates
> >> the deleted flag instead of deleting it. Then any concrete Decorators
> >> extend
> >> the soft delete Decorator, and nothing external has to know whether the
> >> record is actually deleted or soft deleted.
>
> >> On Tue, Mar 3, 2009 at 11:23 AM, Nando wrote:
>
> >> > Rob,
>
> >> > I use soft deletes all the time in Transfer. In essence, it's simply
> >> > an update to a particular column.
>
> >> > My understanding from what Mark has said in the past is that because
> >> > everyone does soft deletes in a different way, in fact your way,
> >> > involving a date field, is different from mine, so it's somewhat
> >> > difficult to implement in Transfer in a way that would work well for
> >> > everyone.
>
> >> > I know Brian Kotek is a big fan of injecting transfer into his
> >> > decorators, precisely into an abstract decorator, wrapping transfer
> >> > methods to enable stuff like myObject.save(). If you adopted that
> >> > approach, you could overwrite the abstract decorator on the concrete
> >> > to enable your approach to soft deletes, even a varying approach as
> >> > you've described, and it would be nicely abstracted away so that
> >> > everywhere in your app you'd call myObject.delete().
>
> >> > I haven't done that in my current app, but I have it mind for next time.
>
> >> > Nando
>
> >> > On Tue, Mar 3, 2009 at 5:08 PM, Sir Rawlins
> > - Show quoted text -
> >> > wrote:
>
> >> > > Hi John, thanks.
>
> >> > > Yeah the way I see its implementation working would be to keep the
> >> > > delete method invoketion the same, just change its implementation
> >> > > dependant on the XML configuration, this would allow some objects to
> >> > > be properly deleted and other only soft deleted likewise with
> >> > > cascading the deletes, sometimes I'll want a parent object to be soft
> >> > > deleted but its children are not audited so they can be properly
> >> > > removed :-)
>
> >> > > I kind of remember someone mentioning it was on the roadmap when I
> >> > > last asked a few months back, perhaps I'll play around with some
> >> > > patches and suggestions for Mark and see if I cant accelerate it a
> >> > > little.
>
> >>
[transfer-dev] Re: Soft Delete?
As you probably know, cascadeDelete() in Transfer "goes everywhere" in
the object graph defined, so especially in the case of deletes, you
probably need to manage how you want it to cascade on a case by case
basis. At least I often always do.
As to your SELECT statements, you simply need WHERE clauses that
exclude them when needed. I don't think there is a simple way around
that, at least not to my knowledge.
On Tue, Mar 3, 2009 at 5:57 PM, Sir Rawlins
wrote:
>
> Wow chaps, a million and one options to choose from eh? great stuff!
>
> @Sean, that's not a half bad idea, I've just always found that in the
> past having things like that split across different resources just
> ends up being a nightmare, its much the same reason I stopped using
> Stored Procs, it just becomes a nightmare trying to maintain things,
> whereas if they're all inside my nice warm codebase then I know where
> to fix issues when they arise ;-)
>
> @ Nando, Brian, that concept certainly seems very attractive, using
> the decorator to do the work, two things jump to mind with this
> though:
>
> 1. cascade deletes, presumably calling ParentObject.delete() will
> invoke my nice soft delete method on the parent, would this in turn be
> able to invoke the children soft deletes? and
>
> 2. Select statements, how could I have both the transfer built in get
> ('someobject', someobject_id) methods and my TQL select methods ignore
> the deleted objects? we also need to bare in mind that in some
> instance, when working with Audit data I will want to pull the deleted
> objects, sometimes I wont.
>
> Cheers for the discussion guys, I appreciate the advice, I just want
> something code-minimal, after all its got to be worth the hassle of
> moving over.
>
> Thanks,
>
> Rob
>
> On Mar 3, 4:30 pm, Brian Kotek wrote:
>> That's exactly how I do this. I'm not a huge fan of ActiveRecord or patterns
>> where objects know how to save themselves, but I've found that the
>> flexibility outweighs the cons. If you have a generic delete() method in
>> your base Decorator, then you can extend it with a SoftDeleteAwareDecorator,
>> which overrides the delete() method and instead does a save() and updates
>> the deleted flag instead of deleting it. Then any concrete Decorators extend
>> the soft delete Decorator, and nothing external has to know whether the
>> record is actually deleted or soft deleted.
>>
>> On Tue, Mar 3, 2009 at 11:23 AM, Nando wrote:
>>
>> > Rob,
>>
>> > I use soft deletes all the time in Transfer. In essence, it's simply
>> > an update to a particular column.
>>
>> > My understanding from what Mark has said in the past is that because
>> > everyone does soft deletes in a different way, in fact your way,
>> > involving a date field, is different from mine, so it's somewhat
>> > difficult to implement in Transfer in a way that would work well for
>> > everyone.
>>
>> > I know Brian Kotek is a big fan of injecting transfer into his
>> > decorators, precisely into an abstract decorator, wrapping transfer
>> > methods to enable stuff like myObject.save(). If you adopted that
>> > approach, you could overwrite the abstract decorator on the concrete
>> > to enable your approach to soft deletes, even a varying approach as
>> > you've described, and it would be nicely abstracted away so that
>> > everywhere in your app you'd call myObject.delete().
>>
>> > I haven't done that in my current app, but I have it mind for next time.
>>
>> > Nando
>>
>> > On Tue, Mar 3, 2009 at 5:08 PM, Sir Rawlins
> - Show quoted text -
>> > wrote:
>>
>> > > Hi John, thanks.
>>
>> > > Yeah the way I see its implementation working would be to keep the
>> > > delete method invoketion the same, just change its implementation
>> > > dependant on the XML configuration, this would allow some objects to
>> > > be properly deleted and other only soft deleted likewise with
>> > > cascading the deletes, sometimes I'll want a parent object to be soft
>> > > deleted but its children are not audited so they can be properly
>> > > removed :-)
>>
>> > > I kind of remember someone mentioning it was on the roadmap when I
>> > > last asked a few months back, perhaps I'll play around with some
>> > > patches and suggestions for Mark and see if I cant accelerate it a
>> > > little.
>>
>> > > Rob
>>
>> > > On Mar 3, 4:01 pm, John Whish wrote:
>> > >> I believe that soft delete is already on the road map. I haven't tried
>> > it,
>> > >> but you should be able to overwrite the Transfer save method to do an
>> > update
>> > >> instead of a delete. So you code would still call the delete method.
>>
>> > --
>>
>> > Nando M. Breiter
>> > The CarbonZero Project
>> > CP 234
>> > 6934 Bioggio
>> > Switzerland
>> > +41 76 303 4477
>> > na...@carbonzero.ch
> >
>
--
Nando M. Breiter
The CarbonZero Project
CP 234
6934 Bioggio
Switzerland
+41 76 303 4477
na...@carbonzero.ch
--~--~-~--~~~---~--~~
Before posting questions to the group please read:
http://groups.go
[transfer-dev] Re: Soft Delete?
Wow chaps, a million and one options to choose from eh? great stuff!
@Sean, that's not a half bad idea, I've just always found that in the
past having things like that split across different resources just
ends up being a nightmare, its much the same reason I stopped using
Stored Procs, it just becomes a nightmare trying to maintain things,
whereas if they're all inside my nice warm codebase then I know where
to fix issues when they arise ;-)
@ Nando, Brian, that concept certainly seems very attractive, using
the decorator to do the work, two things jump to mind with this
though:
1. cascade deletes, presumably calling ParentObject.delete() will
invoke my nice soft delete method on the parent, would this in turn be
able to invoke the children soft deletes? and
2. Select statements, how could I have both the transfer built in get
('someobject', someobject_id) methods and my TQL select methods ignore
the deleted objects? we also need to bare in mind that in some
instance, when working with Audit data I will want to pull the deleted
objects, sometimes I wont.
Cheers for the discussion guys, I appreciate the advice, I just want
something code-minimal, after all its got to be worth the hassle of
moving over.
Thanks,
Rob
On Mar 3, 4:30 pm, Brian Kotek wrote:
> That's exactly how I do this. I'm not a huge fan of ActiveRecord or patterns
> where objects know how to save themselves, but I've found that the
> flexibility outweighs the cons. If you have a generic delete() method in
> your base Decorator, then you can extend it with a SoftDeleteAwareDecorator,
> which overrides the delete() method and instead does a save() and updates
> the deleted flag instead of deleting it. Then any concrete Decorators extend
> the soft delete Decorator, and nothing external has to know whether the
> record is actually deleted or soft deleted.
>
> On Tue, Mar 3, 2009 at 11:23 AM, Nando wrote:
>
> > Rob,
>
> > I use soft deletes all the time in Transfer. In essence, it's simply
> > an update to a particular column.
>
> > My understanding from what Mark has said in the past is that because
> > everyone does soft deletes in a different way, in fact your way,
> > involving a date field, is different from mine, so it's somewhat
> > difficult to implement in Transfer in a way that would work well for
> > everyone.
>
> > I know Brian Kotek is a big fan of injecting transfer into his
> > decorators, precisely into an abstract decorator, wrapping transfer
> > methods to enable stuff like myObject.save(). If you adopted that
> > approach, you could overwrite the abstract decorator on the concrete
> > to enable your approach to soft deletes, even a varying approach as
> > you've described, and it would be nicely abstracted away so that
> > everywhere in your app you'd call myObject.delete().
>
> > I haven't done that in my current app, but I have it mind for next time.
>
> > Nando
>
> > On Tue, Mar 3, 2009 at 5:08 PM, Sir Rawlins
> > wrote:
>
> > > Hi John, thanks.
>
> > > Yeah the way I see its implementation working would be to keep the
> > > delete method invoketion the same, just change its implementation
> > > dependant on the XML configuration, this would allow some objects to
> > > be properly deleted and other only soft deleted likewise with
> > > cascading the deletes, sometimes I'll want a parent object to be soft
> > > deleted but its children are not audited so they can be properly
> > > removed :-)
>
> > > I kind of remember someone mentioning it was on the roadmap when I
> > > last asked a few months back, perhaps I'll play around with some
> > > patches and suggestions for Mark and see if I cant accelerate it a
> > > little.
>
> > > Rob
>
> > > On Mar 3, 4:01 pm, John Whish wrote:
> > >> I believe that soft delete is already on the road map. I haven't tried
> > it,
> > >> but you should be able to overwrite the Transfer save method to do an
> > update
> > >> instead of a delete. So you code would still call the delete method.
>
> > --
>
> > Nando M. Breiter
> > The CarbonZero Project
> > CP 234
> > 6934 Bioggio
> > Switzerland
> > +41 76 303 4477
> > na...@carbonzero.ch
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[transfer-dev] Re: Soft Delete?
That's exactly how I do this. I'm not a huge fan of ActiveRecord or patterns where objects know how to save themselves, but I've found that the flexibility outweighs the cons. If you have a generic delete() method in your base Decorator, then you can extend it with a SoftDeleteAwareDecorator, which overrides the delete() method and instead does a save() and updates the deleted flag instead of deleting it. Then any concrete Decorators extend the soft delete Decorator, and nothing external has to know whether the record is actually deleted or soft deleted. On Tue, Mar 3, 2009 at 11:23 AM, Nando wrote: > > Rob, > > I use soft deletes all the time in Transfer. In essence, it's simply > an update to a particular column. > > My understanding from what Mark has said in the past is that because > everyone does soft deletes in a different way, in fact your way, > involving a date field, is different from mine, so it's somewhat > difficult to implement in Transfer in a way that would work well for > everyone. > > I know Brian Kotek is a big fan of injecting transfer into his > decorators, precisely into an abstract decorator, wrapping transfer > methods to enable stuff like myObject.save(). If you adopted that > approach, you could overwrite the abstract decorator on the concrete > to enable your approach to soft deletes, even a varying approach as > you've described, and it would be nicely abstracted away so that > everywhere in your app you'd call myObject.delete(). > > I haven't done that in my current app, but I have it mind for next time. > > Nando > > On Tue, Mar 3, 2009 at 5:08 PM, Sir Rawlins > wrote: > > > > Hi John, thanks. > > > > Yeah the way I see its implementation working would be to keep the > > delete method invoketion the same, just change its implementation > > dependant on the XML configuration, this would allow some objects to > > be properly deleted and other only soft deleted likewise with > > cascading the deletes, sometimes I'll want a parent object to be soft > > deleted but its children are not audited so they can be properly > > removed :-) > > > > I kind of remember someone mentioning it was on the roadmap when I > > last asked a few months back, perhaps I'll play around with some > > patches and suggestions for Mark and see if I cant accelerate it a > > little. > > > > Rob > > > > On Mar 3, 4:01 pm, John Whish wrote: > >> I believe that soft delete is already on the road map. I haven't tried > it, > >> but you should be able to overwrite the Transfer save method to do an > update > >> instead of a delete. So you code would still call the delete method. > > > > > > > > > -- > > Nando M. Breiter > The CarbonZero Project > CP 234 > 6934 Bioggio > Switzerland > +41 76 303 4477 > na...@carbonzero.ch > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[transfer-dev] Re: Soft Delete?
If you are using SQL Server you can use an INSTEAD OF DELETE trigger. http://msdn.microsoft.com/en-us/library/ms191208.aspx Then you can just let Transfer do its thing, and have your database handle it. Sean On Mar 3, 11:23 am, Nando wrote: > Rob, > > I use soft deletes all the time in Transfer. In essence, it's simply > an update to a particular column. > > My understanding from what Mark has said in the past is that because > everyone does soft deletes in a different way, in fact your way, > involving a date field, is different from mine, so it's somewhat > difficult to implement in Transfer in a way that would work well for > everyone. > > I know Brian Kotek is a big fan of injecting transfer into his > decorators, precisely into an abstract decorator, wrapping transfer > methods to enable stuff like myObject.save(). If you adopted that > approach, you could overwrite the abstract decorator on the concrete > to enable your approach to soft deletes, even a varying approach as > you've described, and it would be nicely abstracted away so that > everywhere in your app you'd call myObject.delete(). > > I haven't done that in my current app, but I have it mind for next time. > > Nando > > On Tue, Mar 3, 2009 at 5:08 PM, Sir Rawlins > > > > wrote: > > > Hi John, thanks. > > > Yeah the way I see its implementation working would be to keep the > > delete method invoketion the same, just change its implementation > > dependant on the XML configuration, this would allow some objects to > > be properly deleted and other only soft deleted likewise with > > cascading the deletes, sometimes I'll want a parent object to be soft > > deleted but its children are not audited so they can be properly > > removed :-) > > > I kind of remember someone mentioning it was on the roadmap when I > > last asked a few months back, perhaps I'll play around with some > > patches and suggestions for Mark and see if I cant accelerate it a > > little. > > > Rob > > > On Mar 3, 4:01 pm, John Whish wrote: > >> I believe that soft delete is already on the road map. I haven't tried it, > >> but you should be able to overwrite the Transfer save method to do an > >> update > >> instead of a delete. So you code would still call the delete method. > > -- > > Nando M. Breiter > The CarbonZero Project > CP 234 > 6934 Bioggio > Switzerland > +41 76 303 4477 > na...@carbonzero.ch --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[transfer-dev] Re: Soft Delete?
Rob, I use soft deletes all the time in Transfer. In essence, it's simply an update to a particular column. My understanding from what Mark has said in the past is that because everyone does soft deletes in a different way, in fact your way, involving a date field, is different from mine, so it's somewhat difficult to implement in Transfer in a way that would work well for everyone. I know Brian Kotek is a big fan of injecting transfer into his decorators, precisely into an abstract decorator, wrapping transfer methods to enable stuff like myObject.save(). If you adopted that approach, you could overwrite the abstract decorator on the concrete to enable your approach to soft deletes, even a varying approach as you've described, and it would be nicely abstracted away so that everywhere in your app you'd call myObject.delete(). I haven't done that in my current app, but I have it mind for next time. Nando On Tue, Mar 3, 2009 at 5:08 PM, Sir Rawlins wrote: > > Hi John, thanks. > > Yeah the way I see its implementation working would be to keep the > delete method invoketion the same, just change its implementation > dependant on the XML configuration, this would allow some objects to > be properly deleted and other only soft deleted likewise with > cascading the deletes, sometimes I'll want a parent object to be soft > deleted but its children are not audited so they can be properly > removed :-) > > I kind of remember someone mentioning it was on the roadmap when I > last asked a few months back, perhaps I'll play around with some > patches and suggestions for Mark and see if I cant accelerate it a > little. > > Rob > > On Mar 3, 4:01 pm, John Whish wrote: >> I believe that soft delete is already on the road map. I haven't tried it, >> but you should be able to overwrite the Transfer save method to do an update >> instead of a delete. So you code would still call the delete method. > > > -- Nando M. Breiter The CarbonZero Project CP 234 6934 Bioggio Switzerland +41 76 303 4477 na...@carbonzero.ch --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[transfer-dev] Re: Soft Delete?
Rob,
I currently handle soft deletes (when required) using a delete() method on
my TO decorator. Say I have a an e-commerce catalog with categories and
items and categories are recursive. If a category has related items or
sub-categories, I want to soft delete. Here's the method to handle that:
if (isParent() || hasItem()) {
// enact soft delete
setIsDeleted(true);
getCatalogDao().save(this);
} else {
getCatalogDao().delete(this);
}
In my service, I would then use something along the line of.
var category = getCategory(arguments.CategoryId);
category.delete();
I prefer this approach since it encapsulates the delete logic in the
business object.
HTH
Paul
On Tue, Mar 3, 2009 at 8:08 AM, Sir Rawlins <
robert.rawl...@thinkbluemedia.co.uk> wrote:
>
> Hi John, thanks.
>
> Yeah the way I see its implementation working would be to keep the
> delete method invoketion the same, just change its implementation
> dependant on the XML configuration, this would allow some objects to
> be properly deleted and other only soft deleted likewise with
> cascading the deletes, sometimes I'll want a parent object to be soft
> deleted but its children are not audited so they can be properly
> removed :-)
>
> I kind of remember someone mentioning it was on the roadmap when I
> last asked a few months back, perhaps I'll play around with some
> patches and suggestions for Mark and see if I cant accelerate it a
> little.
>
> Rob
>
> On Mar 3, 4:01 pm, John Whish wrote:
> > I believe that soft delete is already on the road map. I haven't tried
> it,
> > but you should be able to overwrite the Transfer save method to do an
> update
> > instead of a delete. So you code would still call the delete method.
> >
>
--
Paul Marcotte
Fancy Bread - in the heart or in the head?
http://www.fancybread.com
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[transfer-dev] Re: Soft Delete?
John's right, there is an outstanding enhancement request: http://tracker.transfer-orm.com/issue.cfm?p=89977683-A728-9CD3-ABD9545A91734422&i=0D0237F3-0A4E-B214-130700261356069B but I'm not sure where it is on the road map. I've never done it, but if I was going to try to implement this in an app I'd probably put the logic in the gateway. Assuming all of your Transfer interaction is centralized in your gateway, have a delete() method in the gateway that actually sets the flag and performs an update. You could also add logic to whatever method you have in your gateway for returning Transfer objects (mine's called get()), so that it would not return "deleted" objects. For any method that returns multiple records, you'd need a way of removing "deleted" records from the results. Possibly setting up a method that accepts a query and then does a QofQ to remove any "deleted" records. You could then call that on any result set before doing anything with it. You'd also have to worry about any composites - if an order contains products Transfer wouldn't know to remove the deleted products, but perhaps that could be handled using a condition on your collection (which is supported in the config file). I'm sure that there are other areas that I haven't considered. It wouldn't be simple, but I imagine it's doable. Would be an interesting exercise to see how easy it would be to do. Bob On Tue, Mar 3, 2009 at 11:01 AM, John Whish wrote: > I believe that soft delete is already on the road map. I haven't tried it, > but you should be able to overwrite the Transfer save method to do an update > instead of a delete. So you code would still call the delete method. > > > > -- Bob Silverberg www.silverwareconsulting.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[transfer-dev] Re: Soft Delete?
Hi John, thanks. Yeah the way I see its implementation working would be to keep the delete method invoketion the same, just change its implementation dependant on the XML configuration, this would allow some objects to be properly deleted and other only soft deleted likewise with cascading the deletes, sometimes I'll want a parent object to be soft deleted but its children are not audited so they can be properly removed :-) I kind of remember someone mentioning it was on the roadmap when I last asked a few months back, perhaps I'll play around with some patches and suggestions for Mark and see if I cant accelerate it a little. Rob On Mar 3, 4:01 pm, John Whish wrote: > I believe that soft delete is already on the road map. I haven't tried it, > but you should be able to overwrite the Transfer save method to do an update > instead of a delete. So you code would still call the delete method. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[transfer-dev] Re: Soft Delete?
I believe that soft delete is already on the road map. I haven't tried it, but you should be able to overwrite the Transfer save method to do an update instead of a delete. So you code would still call the delete method. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
