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 < [email protected]> 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 <[email protected]> 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 - > > <[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] > > > -- 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 -~----------~----~----~----~------~----~------~--~---
