Sean, I replaced the event model to facilitate cascading saves and basically everything that's new with the iterator.
About the user.getAddress().delete()... I suppose it's obvious I know it's dangerous if you look at the code. There's a comment that reads as follows: <!--- delete the parent. (By running the next line of code you agree not to sue Doug if something goes horribly wrong.) ---> So... yea, dangerous. I do not intend for this to remain as such forever. The reason it's the way it is now is to facilitate removal of linking records when you call delete on a linked iterator. For example, user.getAddressIterator().delete(1), this needs to delete the userAddres that links the user and address or the delete will throw an error. There are a couple possibilities here though. 1) I could simply make the deletes on linked objects (address) set the related fields in the linking (userAddress) object to "". The problem is that if you call user.save() an error will be thrown. The advantage is that nothing should have been deleted (unless there were some hasMany unlinked relationships - those might be lost.... not sure) 2) I'm pretty sure that I can detect when delete is called on a linked object (address). I think I can do this by looking to see what it's parent's parent has a linking relationship with a type of the current object. In that case you know it's a linking relationship and should be deleted. Otherwise the linking object's (useraddress) will be deleted. Any other suggestions on this? > What about a parent object that hasOne foo and hasOne bar? Yea - those'll be orphaned. Not sure what to do about that at the moment. I don't think they should be deleted. They might belong to another parent too. > addr = user.getAddress(); > addr.delete(); > // user is deleted now, yes? As of now, yes. But as my comments above said, I'm not stuck on it. > // assume parent/foo/bar > foo = parent.getFoo(); > bar = parent.getBar(); > foo.delete(); > // parent and foo are deleted, bar is orphaned Yup. I'm not stuck on it. What do you think this should do? > bar.delete(); // what happens?? Bar is deleted too... though right now it might throw an error. Sean - can you describe what you think should happen in these situations? Others - can you please give me a sanity check on this and Sean's feedback? Thanks, Doug ----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Corfield Sent: Tuesday, April 18, 2006 5:07 PM To: [email protected] Subject: Re: [Reactor For CF] New Commit committed On 4/18/06, Doug Hughes <[EMAIL PROTECTED]> wrote: > 1) The event model is gone (sorry sean, you need to update your preso > again!). This has been replaced in favor of another feature. You didn't say which feature - but it looks like an event model still exists below the surface: see below. > (Note, calling user.getAddress().delete() will delete the user because the > user can't exist without the address, but calling user.delete() will not > delete the address) This is dangerous. What about a parent object that hasOne foo and hasOne bar? If you do parent.delete() you orphan foo and bar, if you call parent.getFoo().delete() you still orphan bar. Also , what about this scenario: 1. addr = user.getAddress(); addr.delete(); // user is deleted now, yes? 2. // assume parent/foo/bar foo = parent.getFoo(); bar = parent.getBar(); foo.delete(); // parent and foo are deleted, bar is orphaned bar.delete(); // what happens?? > Records also have beforeSave(), afterSave(), beforeDelete(), afterDelete() > and beforeLoad() and afterLoad() methods. I suspect theses can be > overridden, but be sure to call the super method! (they're all private so > you can't manually call them.) This smells like an event model to me - how is it different, given that I can override these in my user/custom record CFC? -- Sean A Corfield -- http://corfield.org/ Got frameworks? "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/
