Re: Setting not-nullable field to null - nothing happens
Re: Setting not-nullable field to null - nothing happens
- Subject: Re: Setting not-nullable field to null - nothing happens
- From: Dan Grec <email@hidden>
- Date: Wed, 25 Mar 2009 13:05:27 -0600
On 25-Mar-09, at 12:41 PM, Chuck Hill wrote:
On Mar 25, 2009, at 10:09 AM, Dan Grec wrote:
Hi everyone,
I'm struggling to understand something here and am wondering if
it's a *feature* of WO/EOF.
It is a feature of your understanding. :-P
Are you working on a new book we should know about? "The Long Term
Effects of WO/EOF On The Previously Sane Mind" by Chuck Hill
Psychology Services?
This is one of the things that I am considering presenting on at
WOWODC East or West.
I have an entity called "Category" with a not-nullable "name"
String field. When I create a new one and forget to set a "name"
I get a ValidationException that says "Please provide a Name" and I
spit the user back to the same page (good).
That happens because the user did not change the initial (null)
value so WO did not call setName(). The validity error here is
caught when you call ec.saveChanges() and that causes a call to
validateForSave() on the EO.
If I have an existing Category with a valid name, and I try to set
the name to null, the setter on the entity is never called (I have
logging in there) there is no validation and no SQL is generated.
Oh, there is validation! There is indeed! The input value did
change in this case so WO (specifically the input and associations
aka bindings) tries to set the value. But if it did that directly,
there would be no validation until saveChanges. So instead of using
takeValueForKeyPath it uses validateTakeValueForKeyPath. And it is
NOT valid so this does not result in a call to takeValueForKeyPath.
Instead, it calls
public void validationFailedWithException(Throwable t, Object value,
String keyPath)
Ah-huh! I knew I was missing something. EOF validates things during
the "takeValue.." process, not only during the "saveChanges" process..
I'm learning.
on your component. And I am willing to bet several gallons of beer
that you have not implemented that so the validation error is
quietly discarded (though if you look in the app log you should see
it).
Be careful talking about large quantities of beer, I'm Australian
after all ;)
Thanks Chuck.
So, now what? You can implement this method to record and display
the validation error. Or you can call takeValueForKeyPath(value,
keyPath) to _try_ and force the value in so that the validation runs
the same way you have it now. BUT this might throw if value is not
type compatible, if you are using the ^ notation on bindings etc etc.
The object just remains with it's old name the user moves off to
something else. It is as if they never tried to change it to null.
I would much rather a ValidationException be raised so I can hold
up there user and say "Please provide a Name" to make it clear that
what they were trying to do did not work.
Is it a "feature" of WO/EOF that it won't let you set a not-
nullable to null? Is there any way I can override this behavior?
WO 5.4.3 on 10.5.6
Wonder and WoLips from about 2 weeks ago.
Thanks very much,
-Dan Grec
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden