Re: NeededByEOF0

Patrick Middleton <[email protected]> Thu, 22 Jul 2004 11:10:38 +0100
Newsgroups gmane.comp.web.webobjects.eof
Message-ID <[email protected]>
On Wednesday, July 21, 2004, at 04:50  pm, Clark, Igor wrote:

> Hi folks, getting a strange problem.
>
> I have a Study <<--> Site.
>
> I have a form in which I edit an individual Study.
> This form has a selection box which contains all available sites, with
> study.site bound to the selection binding on the WOPopUpButton. Simple
> stuff.
>
> When I edit an existing study, change the Site, and try to save, for 
> some
> reason EOF tries to update the Site table as well, and causes a primary 
> key
> integrity constraint on the Site table to be triggered. Not only this, 
> but
> it generates SQL for which I have no explanation (names changed to 
> protect
> the guilty):
>
> 	"UPDATE SITE SET ID_SITE = ? WHERE ID_SITE = ?" withBindings:
> 	1:<blah>(NeededByEOF0),
> 	2:<blah>(NeededByEOF0)>
>
> What's NeededByEOF0? A search of the archives for NeededByEOF0 yields
> problems with flattened relationships and propagates primary key, but 
> there
> are no flattened relationships between Study and Site, or any use of
> propagates primary key anywhere.
>
> Does anybody have any ideas or clues as to where to start looking to fix
> this? Makes not a jot of sense to me.

"NeededByEOF0" is a backpointing relationship that EOF adds temporarily 
under the hood when it needs to traverse a relationship that doesn't 
exist.

Does Study have a to-many relationship to Site?

Does Site have a to-one relationship to Study?  You shouldn't need one; 
if you don't have one, it is for this that I'd expect EOF to be creating 
NeededByEOF0.

Check your model, in particular the relationships.  Did a "class 
property" diamond get unset anywhere.  Are you joining on the correct 
primary and foreign keys?  If you're updating Study and you change the 
class property that the join uses, EOF could be trying to propagate this 
change back to Site.  Similar gotchas include trying to set the foreign 
key directly instead of the relationship destination object, and having 
the foreign key be a class property.


Patrick
--
Patrick Middleton
OneStep Solutions plc
351 London Road             Phone: +44 (0)1702 426400
Hadleigh                    Fax:   +44 (0)1702 556855
Essex. SS7 2BT              Email: [email protected]
England                            (MIME welcome)