WEIRD bug thing; 'shared' as reserved word? can you explain it?
WEIRD bug thing; 'shared' as reserved word? can you explain it?
- Subject: WEIRD bug thing; 'shared' as reserved word? can you explain it?
- From: Jonathan Rochkind <email@hidden>
- Date: Thu, 06 Feb 2003 15:20:30 -0600
Okay, I kind of have this figured out now, but it took me half a day to
track down. Can anyone explain why 'shared' is a name you should avoid
using for an attribute in your EOs? In my migration from 5.0 to 5.2, I
discovered this. Even though it didn't cause a problem in 5.0, it caused a
weird problem I can't entirely explain in 5.2, but changing the attribute
name fixed it.
For those really interested, here's a description. If you can come up with
a coherent explanation of what's going on, you get my eternal respect as a
true WebObjects genius-guru-expert.
I have an attribute called 'shared'. I use it as a boolean switch,
although in the db it's a numeric type. In 5.0, this means EOF would return
it as an Integer, and I wrote my own method to convert it to a small-b
boolean, no problem:
public boolean shared() {
return numberToBoolean( storedValueForKey("shared" );
}
public void setShared(boolean newShared) {
takeStoredValueForKey( booleanToNumber( newShared ), "shared");
}
Everything worked fine, but (this is important in a second), there COULD be
null values in the db. No problem, my conversion method converted them to
false. There were no problems.
Now, I convert to 5.2. In 5.2, if you have an attribute named 'foo', and a
method named foo() returning a boolean, like I had for 'shared',
storedValueForKey will automatically translate the numeric data to a
capital-B Boolean. Of course, I'm using a small-b boolean, no big deal,
but now my methods can simply look like this:
public boolean shared() {
return ((Boolean) storedValueForKey("shared")).booleanValue();
}
public void setShared(boolean newShared) {
takeStoredValueForKey( new Boolean(newShared), "shared");
}
Okay, no problem, for values in the db 1 and 0 (which is most of them),
this actually works fine. BUT. For null values in the db.... upon fetching
a row that has a null in the 'shared' column, I get an key value coding
exception, unable to assign null to key shared. Of course I can't assign
null with the setShared method, but why is it even using the setShared
method, it should just be using takeStoredValueForKey to initialize the new
EO, no? And the million dollar question---if my attribute is called
anything else but shared, this works FINE. NULL is reasonably translated
to a Boolean 'false', there is no exception. It's only when the attribute
is called 'shared' that there is a problem.
So, after a day of messing with this, I know I need to change the name of
my attribute to something to something other than 'shared'. Good enough,
it's a pain to make sure I haven't missed any EOQualifiers with 'shared' in
them, but at least I know what must be done. But I am still completely
baffled as to why. What's so special about the word 'shared' that makes
things fail in such a truly bizarre way----that is, only fail in very
unusual circumstances (null value in the db that normally you wouldn't
expect), and only when the attribute is named 'shared'. Anyone?
--Jonathan
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.