Re: Re : EOGeneralAdaptorException : deleteRowDescribedByQualifierEntity
Re: Re : EOGeneralAdaptorException : deleteRowDescribedByQualifierEntity
- Subject: Re: Re : EOGeneralAdaptorException : deleteRowDescribedByQualifierEntity
- From: Chuck Hill <email@hidden>
- Date: Mon, 21 Mar 2005 16:19:23 -0800
On Mar 21, 2005, at 4:00 PM, Marc-Alexis Côté wrote:
I have set the relationships to "own destination"
That may not be what you want. This will automatically create the
related objects for you. I see in your code below that you are also
manually creating them. That may be the cause, or a contributing
factor, in your problem.
and cascade.
That is probably the only thing you need: delete the addresses if the
dealer is deleted.
If I delete a Dealer directly, I still get the error. Note that in my
previous example, I
was incorrectly using addToBothSidesOfRelationshipWithKey and
removeObjectFrom... when the relationships were unidirectional.
That will not matter. addToBothSidesOfRelationshipWithKey inspects the
model and does the right thing.
I have tried debugging this problem by putting all the code in a single
component with two buttons: Create Dealer and Delete Dealer. This is as
simple as it can get. And it still crashes with the same exception.
This
leads me to believe that there is something that I clearly don't
understand... Here is a little example I have put together: (I hope I
am not
going against list policies by posting code...)
I think the only policy is "play nice". :-)
public class Test extends WOComponent {
protected EOClassDescription dealerDescription;
protected EOClassDescription addressDescription;
protected Dealer dealer;
public Test(WOContext context) {
super(context);
dealer = null;
}
public void awake() {
EOEditingContext ec = session().defaultEditingContext();
dealerDescription =
EOClassDescription.classDescriptionForEntityName("Dealer");
addressDescription =
EOClassDescription.classDescriptionForEntityName("Address");
This is more work than you really need to do. See below.
}
public WOComponent create() {
EOEditingContext ec = session().defaultEditingContext();
Address shippingAddress =
(Address)addressDescription.
createInstanceWithEditingContext(ec, null);
Address shippingAddress =
(Address) EOUtilities.createAndInsertInstance(ec,
"Address");
See below for problem with your code.
ec.insertObject(shippingAddress);
shippingAddress.setAddress1("Shipping");
shippingAddress.setCity("Somewhere");
shippingAddress.setPostalCode("12345");
shippingAddress.setState(null);
shippingAddress.setCountry(null);
Address billingAddress =
(Address)EOUtilities.createAndInsertInstance(ec,
"Address");
ec.insertObject(billingAddress);
billingAddress.setAddress1("Billing");
billingAddress.setCity("Somewhere");
billingAddress.setPostalCode("12345");
billingAddress.setState(null);
billingAddress.setCountry(null);
dealer =
(Dealer)dealerDescription.
createInstanceWithEditingContext(ec, null);
ec.insertObject(dealer);
At this point EOF has already created Address objects for
administrativeAddress() and shippingAddress() and inserted them into
the ec (assuming you have indicated Owns Destination).
dealer.setAdditionalInformation("");
dealer.setContactName("Marc-Alexis");
dealer.setDealershipName("Something");
dealer.setEmail("email@hidden");
dealer.setFaxNumber("0123456789");
dealer.setPassword("blahblah");
dealer.setPhoneNumber("0123456789");
dealer.setUsername("marcalexis");
dealer.setAdministrativeAddress(billingAddress);
dealer.setShippingAddress(shippingAddress);
Here are you casting the objects that EOF has created into the void
(well, OK, leaving them hanging around in the EC). The fact that it
works if you restart the application means that the contents of the EC
are somehow scrambled. I think that Owns Destination is the cause of
your problems.
If you want Owns Destination, then move the code that initializes the
addresses down here an use dealer.shippingAddress().setAddress1("fff")
etc.
ec.saveChanges();
return null;
}
public WOComponent delete() {
EOEditingContext ec = dealer.editingContext();
ec.deleteObject(dealer);
ec.saveChanges();
return null;
}
Thanks for the tip about EOCustomObject and the editingContext()
method.
Chuck
Le 21/03/05 06:11, « Florijan Stamenkovic » <email@hidden> a écrit :
On Mar 21, 2005, at 00:49, Marc-Alexis Côté wrote:
Hello,
I am a new WebObjects developer and I am struggling with an issue. I
am
developing a relatively simple application. I have a Dealer entity
which has
a relationship to two Address entities. I get a
EOGeneralAdaptorException
(deleteRowDescribedByQualifierEntity) exception when I try to delete
a
Dealer entity in the same session that I create it.
At first I created the EOModel so that the address entities would be
deleted
when a Dealer is deleted. However, that makes my application crash
with the
above exception. If I set the relationship to "Nullify", then I don't
get
the exception. This leads me to believe that the problem occurs when
deleting the relationship. In order to further investigate the
problem, I
tried deleting the objects by hand:
EOEditingContext ec = session().defaultEditingContext();
Address sAddress = aDealer.shippingAddress();
Address aAddress = aDealer.administrativeAddress();
aDealer.removeObjectFromBothSidesOfRelationshipWithKey(sAddress,
"shippingAddress");
aDealer.removeObjectFromBothSidesOfRelationshipWithKey(aAddress,
"administrativeAddress");
ec.deleteObject(aDealer);
ec.saveChanges();
This works like a charm. However, if I go further along, this is
where
things go wrong:
ec.deleteObject(aAddress);
ec.deleteObject(sAddress);
ec.saveChanges();
you deleted the object that the addresses are related to already. if
the addresses have a mandatory relationship towards dealers you have a
problem there... in such a situation i would set the relationships
from
dealer to those two addresses to cascade delete and use code like:
ec.deleteObject(aDealer);
ec.saveChanges();
if you really must delete by hand, delete the addresses first (but
then
the address relationships from your dealer should be optional and not
mandatory, and reverse relationships set to nullify) and then before
saving changes to the ec, delete the dealer. can't see why it wouldn't
work if your model is ok...
oh, one more thing. everything that inherits from EOCustomObject, so,
all your "business" classes, implements the editingContext() method,
and it's normally good practice to delete objects like the following
code, even if you only use the default editing context...
EOEd... ec = aDealer.editingContext();
ec.deleteObject(aDealer);
I get the following exception (which is the same as when the address
relationship is set to cascade):
Application: WoTuppSite
Error: com.webobjects.eoaccess.EOGeneralAdaptorException:
deleteRowDescribedByQualifierEntity --
com.webobjects.jdbcadaptor.JDBCChannel: method failed to delete row
in
database
Reason: deleteRowDescribedByQualifierEntity --
com.webobjects.jdbcadaptor.JDBCChannel: method failed to delete row
in
database
I know I am doing something wrong, because it works if I close the
application and restart it. Can anyone tell me what I missed?
well, this wasn't really a solution, just some thoughts. hope it
brings
you some...
cheers
florijan
Thanks,
Marc-Alexis
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
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:
village.net
This email sent to email@hidden
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development 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