I'm in the midst of doing some archival code. Once my objects are
copied off into their archival EOs, I then run this line:
ec.deleteObject(thisApplicant);
I get tons of exceptions based on NSValidationErrors, as various
foreign keys won't be satisfied. Example:
An Exception occured while trying to save the information:
com.webobjects.foundation.NSValidation$ValidationException: The
applicant property of Eval must have a Applicant assigned
My various delete rules in my model are all nullify. I'm presuming
that I need CASCADE instead to resolve the foreign key
management? Or
is it simply a matter of changing the optionality to Optional from
Mandatory?
If deleting those objects is OK, then a CASCADE rule is what you
want.
Otherwise, make the relationships optional. You will probably
need to
update the nullity of the database columns too.
Well, I changed to cascade to test out that theory, and it seems to
get past those steps, but I'm getting a more esoteric error now for
each delete. Does this sound familiar?
<low whistle>
Um, no. That is (happily) not familiar at all.
An Exception occured while trying to save the information:
com.webobjects.eoaccess.EOGeneralAdaptorException: The attribute
NeededByEOF0 should be assigned a Number, but the value was the
String
"20"
Its always the same line with simply String "20 switching to "56"
"14"
"66" "29" etc.
Any idea what this value is? A PK/FK? Some data? NeededByEOF0 is
usually
EOF creating temporary things it needs to walk the object graph.
Do you
have any exposed (class property) FK attributes?
I think I found the problem in a flatten attribute.
Flattened attributes are always dodgy IMO.
I was able to fix
that. What was left was a lot of errors on constraints again. I had a
lot of constraints in the database such as:
ALTER TABLE ONLY "language"
ADD CONSTRAINT language_application_num_fk FOREIGN KEY
(application_num) REFERENCES applicant(id) DEFERRABLE INITIALLY
DEFERRED;
ALTER TABLE ONLY lor
ADD CONSTRAINT lor_application_num_fk FOREIGN KEY
(application_num) REFERENCES applicant(id) DEFERRABLE INITIALLY
DEFERRED;
when I delete applicant even with the cascade from applicant to
language it would fail to remove barf about not meeting the
constraint. I'm wondering if nullify needs to be switch to cascade
even for one-to-one relations. I removed all the database constraints
to test and everything works now.
I'm wondering if WebObjects even needs that constraints or should
have them.
Again, if those objects should get deleted as part of this operation,
even to-one should have cascade. No action might also be appropriate.
Chuck
--
Chuck Hill Senior Consultant / VP Development
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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
