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 <d.na...@gmail.com> 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
>
>
>
> <robert.rawl...@thinkbluemedia.co.uk> 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 <brian...@gmail.com> 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 <d.na...@gmail.com> 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 -
> >> > <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 <john.wh...@googlemail.com> 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.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
-~----------~----~----~----~------~----~------~--~---
