Re: A Bad Bug?
Re: A Bad Bug?
- Subject: Re: A Bad Bug?
- From: Jean Pierre Malrieu <email@hidden>
- Date: Tue, 19 Sep 2006 21:37:40 +0200
Le 19 sept. 06 à 19:03, Ken Anderson a écrit :
I have hundreds of one-way relationships and they work just fine in
the latest WO release.
I am glad for you! And this gives me hope after a difficult
programming week...
I have created a very simple test to double check this issue.
Assume you have A->>B and not B->A
call
entityA_instance.addObjectToBothSidesOfRelationshipWithKey
(entityB_instance, "entityBs");
then
entityA_instance.entityBs() will indeed contain entityB_instance.
But upon saveChanges(), no sql will be generated to update
entityB_instance corresponding row. The foreign key is not updated,
and on subsequent fetches, entityA_instance.entityBs() will no longer
contain entityB_instance.
I can send you the test case if you want, but you can reproduce it in
no time.
Whether this is a bug or a logical behavior is another question.
JPM
On Sep 19, 2006, at 12:49 PM, Jean Pierre Malrieu wrote:
What version of WO are you using?
Relationships have started to behave strangely since 5.3.2., I fear.
For example a to-many with no reverse to-one relationship no
longer works with 5.3.2 (foreign key is not updated in sql).
JPM
Here is one that bit me bad yesterday. I am trying to understand if
it is really a bug situation or not, or whether the code I used is
expected to produce unpredictable behavior like this did.
I was using eoSourceObject.takeValueForKey( destObject,
relationshipKey ) to set a relationship. Upon saving the
eoSourceObject had the corrected related object and the editing
context state was correct with the relationship made, etc. I could
navigate the EC and objects in the EC using the DebugMarker and ec
examination pages in Project Wonder. SO basically as far as the EOF
was concerned, all changes had been saved and the current state of
the EC reflected the current state of the database.
However the foreign key was actually not getting updated in the
eoSourceObject table. Logging SQL showed that indeed this was the
case. The source object was written out to the database with the old
foreign key even though the ec had the new related object!
Now digging a little deeper, the takeValueForKey was calling the
auto-
eogenerated code which in turn called takeStoredValueForKey
(CTMediaTemplate is the destination object here and this method
is in
the eogenerated _CTCampaign, the source object.)
public void setMediaTemplate(CTMediaTemplate aValue) {
if( log.isDebugEnabled() ) log.debug( "updating
mediaTemplate from "+mediaTemplate()+" to "+aValue );
takeStoredValueForKey(aValue, "mediaTemplate");
}
At face value, it seemed like everything was fine and confirmation
pages of the saved state of the EC showed everything OK ..... but
later once the snapshot expired, the snapshot got updated form the
database and the OLD original foreign key showed up and then the
wrong related destObject was displayed ..... AAARRRGGGHHH!!!
The SOLUTION was to change my code to use
eoSourceObject.addObjectToBothSidesOfRelationshipWithKey
( destObject,
relationshipKey);
.....but WHY does not takeValueForKey or takeStoredValueForKey not
set the relationship both ways?
Kieran
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40anderhome.com
This email sent to email@hidden
_______________________________________________
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