Re: Delete cascade?
Re: Delete cascade?
- Subject: Re: Delete cascade?
- From: Ian Joyner <email@hidden>
- Date: Tue, 20 Mar 2007 10:20:34 +1100
On 20/03/2007, at 2:57 AM, Chuck Hill wrote:
On Mar 18, 2007, at 10:11 PM, Ian Joyner wrote:
Hi Peter,
What you say makes sense. Maybe, because my dependent entity does
not have any further cascades, I'm not seeing anything else being
brought into memory (maybe it's already there).
I think what I would expect is to see is:
SELECT * FROM <owned_table> WHERE OWNER_KEY = <PRIMARY_KEY of owner>
<processing of any cascades from those records>
DELETE FROM <owned_table> WHERE OWNER_KEY = <PRIMARY_KEY of owner>
That is not safe. What if records were added to <owned_table> with
an OWNER_KEY = <PRIMARY_KEY of owner> while you were processing the
cascades?
My unease is growing here, but then again I suspect it must be right
because it has been in operation for such a long time. I would guess
that WO is handling the cascades due to underlying DBs handling them
in different ways. I think records could be added to the
<owned_table> by another transaction from another user in any
situation, unless maybe the whole table is locked, or at least the
parent record is locked in such a way that owned records cannot be
added. So you want the DELETE to be atomic.
I suspect that is why the designers of EOF elected to not use this
"optimization". Generally, they seem to have chosen safe over fast
in implementing EOF.
I agree with that, but I have a feeling that expanding the
transaction over time makes for more chance for untoward things to
happen. However, limiting the possibility for a race condition to
occur does not mean that it won't occur and have very nasty
consequences.
Thanks for your and Peter's answers, I don't want to waste anymore of
people's time on it, since the answer seems to be that it's working
as intended (and hopefully correctly) so it's nothing I'm doing
that's stupid to cause seemingly non-optimum (and I hope safe)
behaviour. I don't believe this is covered in the wikibook yet.
Chuck
However, all I see is the DELETEs a single one at a time. Maybe I
just have an simple case?
Thanks
Ian
On 19/03/2007, at 2:08 PM, Peter Vandoros wrote:
Hi Ian,
WebObjects does this because it needs to bring all the EO's into
memory to process the delete rules specified in your EOModel.
Regards
Peter
Ian Joyner wrote:
I just noticed in my system that if I have the cascade delete
rule set on a to-many relationship in EOModeler that the deletes
happen one by one.
That is if I have a master record with three detail records, WO
issues three SQL DELETEs.
The setup is, each record has a primary key PRIMARY_KEY, which
relates to the owned records which have OWNER_KEY. To do the
delete cascade, I would think that DELETE FROM <owned table>
WHERE OWNER_KEY = <PRIMARY_KEY of owner> would suffice.
Have I got something set up wrong here, or am I missing something?
Thanks
Ian Joyner
Sportstec
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40etechgroup.com.au
This email sent to email@hidden
--This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
Peter Vandoros
Software Engineer
Etech Group Pty Ltd
Level 3/21 Victoria St
Melbourne VIC 3000
Australia
Ph: +61 3 9639 9677
Fax: +61 3 9639 9577
----------------------------------
IMPORTANT: This e-mail message and any attachments are
confidential and may be privileged. If received in error, please
reply to this message and destroy all copies and any attachments.
You should check this message and any attachments for viruses or
defects. Our liability is limited to resupplying any affected
message or attachments. For more information about Etech Group,
please visit us at http://www.etechgroup.com.au.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40sportstec.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden