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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 - >> > <[email protected]> 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 <[email protected]> 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 >> > [email protected] > > > -- Nando M. Breiter The CarbonZero Project CP 234 6934 Bioggio Switzerland +41 76 303 4477 [email protected] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
