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
> > <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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
