Then if I had a user that had an address and I wanted to delete both, I could have one of 2 situations.
a) I could have already opted in on Cascading Delete in the config file.
b) I could have code like such:
user.setCascadeDelete(true);
user.delete();
user.delete();
Well, I'm already looking at it and seeing that it has the same issue with "CascadeDelete" being a column name and interfering with the get/set methods...
I'm just glad that Doug came to his senses :-). I look forward to trying out all this new iterator stuff when deleting an address won't delete a user.
Maybe it's best to just purposefully delete things, so that no mistakes happen?...
On 4/18/06, Doug Hughes <[EMAIL PROTECTED]> wrote:
"cascade" seems like a term more likely to appear as a db column name than
cascadeDelete or cascadeSave
Doug
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
Of João Fernandes
Sent: Tuesday, April 18, 2006 7:24 PM
To: [email protected]
Subject: RE: [Reactor For CF] New Commit committed
Doug,
I like the option of cascading and why not use the same argument cascade =
true:false on a method?
user.save(userid=123,cascade=true)
user.delete(userid=123,cascade=true)
João Fernandes
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of Doug Hughes
Sent: Wed 19-Apr-06 12:18 AM
To: [email protected]
Subject: RE: [Reactor For CF] New Commit committed
The more I think about this, the more obvious it is that it was half-witted
to delete up.
Seriously! The concept that deleting an address would delete a user? Ha!
Furthermore, if a user hasOne address (user.addresId = address.addressId)
then you can't guarantee that there won't be errors on delete anyhow. Any
number of users could haveOne of the address you're deleting and the DB
server would throw an error. So, if you can't delete something because of
constraints, you can't delete it. Fine!
I also don't think that deleting an address should reset any values on the
user. In the grand scheme of things, I don't think it'd make a difference.
If you want to remove an address from a user call removeAddress() (which is
a new method, by the way!)
I think that I'm going to simply remove this "ability".
There is room for cascading on delete and making it optional on saves.
Right now, with the delete method, if you pass in any list of name/value
pairs the corresponding record will be loaded and deleted. I could add one
"reserved" argument which would be used to indicate if you wanted the delete
to cascade. For example, the following would delete without a cascade:
User.delete()
Or
User.delete(userId=123)
The following would delete with a cascade:
User.delete(true)
Or
User.delete(cascadeDelete=true, userId=123)
I'm thinking that cascadeDelete would only "work" when any other arguments
are passed in when it's the first argument and it's a Boolean. For example:
User.delete(userId=123, cascadeDelete=true)
This would delete the record with a userID of 123 and a cascadeDelete of
true.
On saves this might be easier. I don't recall for sure, but I don't think
save accepts arguments. In this case the arguments are easier. This code
would cause any loaded dirty children (anywhere down in the proverbial tree)
to save themselves:
User.save()
This would only save the current user but not any dirty children:
User.save(false)
Or
User.save(cascadeSave=false)
Thoughts?
Doug
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
Of Sean Corfield
Sent: Tuesday, April 18, 2006 7:04 PM
To: [email protected]
Subject: Re: [Reactor For CF] New Commit committed
On 4/18/06, Doug Hughes < [EMAIL PROTECTED]> wrote:
> I replaced the event model to facilitate cascading saves and basically
> everything that's new with the iterator.
Figured.
> 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.
OK. Good to know. Right now it would be unusable in most applications,
I believe, since it would cascade *UP* which is definitely not good.
Cascading *down* is fine (as long as there is an option to *not* do
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?
If foo really is a dependent object (i.e., parent requires foo and foo
requires parent), then I think it should be an error to delete foo (or
bar). Deleting parent should delete foo and bar (if casading deletes
is enabled).
I just don't think you should be able to delete from the bottom up.
--
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/
-- 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/
--
Chris Phillips
www.dealerpeak.com
Senior Application Developer -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/
