RE: mysterious EOF problem: not inserting all fields
RE: mysterious EOF problem: not inserting all fields
- Subject: RE: mysterious EOF problem: not inserting all fields
- From: <email@hidden>
- Date: Wed, 7 Apr 2004 08:51:43 +0200
- Thread-topic: mysterious EOF problem: not inserting all fields
Hi!
Three more approaches:
1. Get rid of the setter method. Pass the initial value to the constructor, stow it away and set it using takeStoredValueForKey during awakeFromInsertion.
2. Use the differences between validateForUpdate(), validateForInsert() and validateForSave() to determine when to accept a value differs from one detected during awakeFromFetch().
3. Write a validateAttribute() method that returns the first non null value (i.e. from an instance variable) encountered in either validateAttribute() or awakeFromfetch(). It would return the value it is passed as argument only if no previous value is known.
Pierre
-----Original Message-----
From: Jonathan Rochkind [mailto:email@hidden]
Sent: Tuesday, April 06, 2004 9:18 PM
To: Dov Rosenberg; email@hidden
Subject: Re: mysterious EOF problem: not inserting all fields
At 3:07 PM -0400 4/6/04, Dov Rosenberg wrote:
>You didn't mention your database that your using or the data types of the
>columns being affected. You might want to consider the following:
MS SQL Server 7. The column that is not being included in the INSERT
is a varchar/String. Nothing weird.
>* Make sure that the model plist files are correct and have the correct user
>permissions
Aha! Thank you! I was thinking, geez, what's the point of looking at
the plist file directly, I've been looking at the model in EOModeler,
and it's all as expected. But, looking at the plist file directly
made it easier for me to find the problem: The attribute in question
had somehow gotten "isReadOnly=Y" set! Of course, if EOF thought
this attribute was read only, that would explain the problem! Thanks!
The interesting thing, is that this attribute really ought to be read
only, ONCE the thing is inserted! EOF needs to allow me to insert it,
but I'd be happy if EOF prevented me from _changing_ it after that
point. It's probably with that in mind that I set the attribute to be
"read only" at some point, and forgot about it, not realizing that
EOF would stop me from _inserting_ those read only columns too!
Okay, turn off read only, problem solved.
As an alternate question, if anyone is still reading: what's the best
way to enforce what I really want to do? That is, allow me to
specify a value for that attribute upon insert, but prevent any code
from _changing_ that value for an already inserted object?
--Jonathan
>
>* make sure that your generated java classes contain the methods that you
>expect and they match the expected output based on the EOModel.
>
>* Check the meta data info at the top of your index.eomodeld file by viewing
>it in a text editor - make sure they match your database
>
>* try browsing the database using either DBEdit or EOModeler.
>
>* If you are using Prototypes, make sure the definitions are correct.
>
>HTH
>
>
>
>On 4/6/04 2:37 PM, "Jonathan Rochkind" <email@hidden> wrote:
>
>> I have an EO class, with a bunch of attributes. One of these
>> attributes is marked non-nullible in the model, and also in the
>> database.
>>
>> When a create and insert a new one in code, of course I set this
>> attribute. Before calling saveChanges, I check in my debugger to make
>> sure that attribute has a value---it does. I call saveChanges. EOF
>> validation does _not_ raise an exception, complaining that this
>> attribute is not allowed to be null. Which I do not expect it to, of
>> course, because that attribute is NOT null.
>>
>> However, when EOF actually sends an SQL insert to the database----the
>> insert statement does not include this attribute! And then of course
>> my database complains about that attribute not being allowed to be
>> null, and rejects the insert. Huh? Why is EOF not listing all
>> attributes in the insert? Yes, the attribute in question is marked as
>> a class property.
>>
>> To make matters more confusing---this problem seems to have just
>> randomly started. I can't figure out what I have changed to make this
>> problem start, when the problem did not previously exist, for the
>> same code I am testing.
>>
>> Anyone have any ideas at all? I'm at my wits end here. Somehow this
>> problem got deployed (I swear, it didn't show up in testing, that's
>> the weird thing---although now I can reproduce it on my local machine
>> as well as the deployment machine), so I've got to get it fixed asap.
>>
>> --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.
>>
>
>--
>Dov Rosenberg
>Conviveon Corporation
>http://www.conviveon.com
_______________________________________________
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.
**********************************************************************
This email and any files transmitted with it are intended solely for
the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender
of this message. (email@hidden)
This email message has been checked for the presence of computer
viruses; however this protection does not ensure this message is
virus free.
Banque centrale du Luxembourg; Tel ++352-4774-1; http://www.bcl.lu
**********************************************************************
_______________________________________________
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.