Re: Setting Default Values EOModeler
Re: Setting Default Values EOModeler
- Subject: Re: Setting Default Values EOModeler
- From: Chuck Hill <email@hidden>
- Date: Tue, 2 Aug 2005 11:30:37 -0700
On Aug 1, 2005, at 12:42 PM, Anjo Krank wrote:
Am 01.08.2005 um 20:34 schrieb Chuck Hill:
On Jul 31, 2005, at 11:26 PM, Anjo Krank wrote:
Am 30.07.2005 um 01:45 schrieb Chuck Hill:
Not in EOModeler, but you can do it in the awakeFromInsertion
method of the EOEnterpriseObjects. That is the proper way to do
this.
It would be... if a failed ec.saveChanges wouldn't re-insert deleted
objects into the EC, leading to a call to awakeFromInsertion() all
over again. As an additional measure, you should factor out this
code into a "protected void initialize()" and only call it from
awakeFromInsertion when the GID is not a temporary one (David
Teran's idea, never tested it but it sounds like it should work).
What sort of failed saveChanges()? I've seen this when a delete rule
was set to deny or validateForDeletion threw. In those cases the EC
state is totally trashed.
It might well have been a cascading delete, but I don't really
remember.
That the state is "totally thrashed" is a bug of it's own, though.
What's the bug number?:)
3155914 still open...
24-Jan-2003 12:10 PM Chuck Hill:
* SUMMARY
There is a rather serious bug when validateForDelete() fails to allow a
deletion. This will occur if you are using the Deny delete rule, the
relationship is mandatory, or you have a custom validateForDelete()
method. This results in the editing context undoing several steps to a
historical state.
* STEPS TO REPRODUCE
The error occurs in this scenario:
1. The editing context has multiple generations, meaning that
saveChanges() has been called one or more times after one or more EOs
has been created / inserted / updated.
2. An EO is deleted from the editing context by deleteObject().
3. saveChanges() fails due to an NSValidation.ValidationException
raised in validateForDelete.
* RESULTS
This result of this appears to be that undo() is called on the editing
context's undo manager too many times. Instead of rolling back to the
state when saveChanges() was called it rolls back past several of
previous saveChanges()! The result of this is:
a. The editing context shows a historical state that does not match the
object store or the database
b. Despite the difference in states, the editing context says that it
has no changes.
c. Calling saveChanges() on the editing context does not result in an
update of the object store but the editing context still retains the
historical data. So with this code,
ec1.saveChanges(); // Show that there are no uncommited changes.
EOEditingContext ec2 = new EOEditingContext();
ec2.setFetchTimestamp(1);
EnterpriseObject eoClone = EOUtilities.localInstanceOfObject(ec2, eo);
The attributes and relationships of eo and eoClone will not be the same
(eo showing the historical data)..
* REGRESSION
N/A
* NOTES
Will send reproduction case demonstrating problems and work arounds.
Chuck
--
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