Re: Empty relationship that isn't null >> problem with one-to-one
Re: Empty relationship that isn't null >> problem with one-to-one
- Subject: Re: Empty relationship that isn't null >> problem with one-to-one
- From: DevReseune <email@hidden>
- Date: Tue, 31 May 2005 22:21:07 +0200
It's not a real one-to-one as in Hibernate. EOF thinks that for one
side, the related object has to exist. In my application, all
entities can exist without the others. EOF can't do that. Is it true?
Is it the same thing with CoreData?
Frédéric
Le 30 mai 05 à 18:33, Chuck Hill a écrit :
On May 29, 2005, at 10:37 AM, DevReseune wrote:
Thanks for your help.
I understood my problem: I created an one-to-one relationship, but
WO doesn't love this type of relationship.
Wrong. You modeled the relationship incorrectly and EOF does not
love incorrect modeling. I use one to one all the time.
So, I just inverted the role of entities in database (PARENT has
now a CHILDID property), and all works well.
Yes, that is correct modelling.
PS: so, Hibernate is better than WO?
Why do you think that?
Chuck
Le 24 mai 05 à 22:17, Chuck Hill a écrit :
On May 22, 2005, at 9:31 AM, DevReseune wrote:
Hi,
Thanks for your response, but my problem is still there.
I resume with more details:
#1
I have 2 entities:
- PARENT:
- PK: String ID
- to-one relationship: CHILD child with:
- PARENT.ID = CHILD.PARENTID
That sounds like a to-many relationship. The database makes no
guarantee that child.parentid is unique. Check how you have
modelled this. Usually you want the child's PK as an FK in the
Parent to enforce to-one.
- optionnal
- delete rule: nullify
- owns destination: no
- propagate primary key: no
- CHILD
- PK: String PARENTID
NOTE: PARENT is related with another entity, and the primary key
of PARENT is the primary key of this other entity.
That can be a problem if this other entity is missing from the
DB. EOF will assume that it exists and create an empty place
holder for it.
#2
In database, I have only 2 PARENTs, and 0 CHILD.
#3
First, I fetch all PARENTs:
- EOF calls a SQL request to load all PARENT
- the attribute PARENT.child is initiated with a
EOAccessDeferredFaultHandler object
It seems odd that you can see this. EOF should have fired it.
It is very unusual to actually 'see' a fault.
> update with takeStoredValueForKey
#4
So, in another page, I show an PARENT:
- EOF calls a SQL request to load a related CHILD with PARENT
> the response is "0 row(s) proceed". It's true, no CHILD exists
in database
- he attribute PARENT.child is setted with a
_EOVectorKeyGlobalID object with all its properties are
> update with takeStoredValueForKey
What are the contents of the that globalD? What do you mean "the
attribute PARENT.child is setted with a _EOVectorKeyGlobalID". A
global ID is associated with an EO, but it can't be set in place
of one. And what do you mean by "with all its properties are
update with takeStoredValueForKey"?
I really think that something in your model is not really as you
think it is (hint, look again, carefully) or that you have done
something very stange in the model.
Chuck
Any suggestion?
Frédéric
Le 18 mai 05 à 22:23, Ken Anderson a écrit :
To expand a little bit on what Chuck is saying, if a value
exists in a column being used to construct a relationship, EOF
believes that the related object exists. If you use the same
primary key for related EO's (for instance, a primary EO, and
an optional 'sidecar' object), you can run into this problem,
since the primary key of the primary EO always exists, it is
expected that the related object always exists.
This occurs often in databases that were designed without EOF
in mind. A typical way to work around this is to make the
relationship to-many, then have a custom accessor in the EO of
the single variety that either returns toMany.firstObject() or
nil, depending on whether there's a count on the relationship
or not.
Ken
On May 18, 2005, at 4:12 PM, Chuck Hill wrote:
We are talking about a specific object that is related to a
specific row in the database. Does that row have a non-null
value for the EntityB FK? If so, is it valid or do you have a
referential integrity problem in your data? If you have a
referential integrity problem (which is what it sounds like),
then you are seeing what is called a "Dummy Fault EO" see
http://lists.apple.com/archives/webobjects-dev/2003/Aug/
msg00433.html and other Google hits.
Chuck
On May 18, 2005, at 12:46 PM, DevReseune wrote:
Hi,
It's an optional to-one relationship, there is none EntityB
in database, and the entityB FK is null by default, but this
property is hidden (not the related object, but its ID).
I don't understand.
Frédéric
Le 16 mai 05 à 21:24, Chuck Hill a écrit :
This is a to-one relationship? Is it marked as optional or
mandatory? Is the entityB FK in the EntityA object null, or
does it have a value?
Chuck
On May 16, 2005, at 11:19 AM, DevReseune wrote:
Hi,
I have 2 entities bound with a relationship:
- EntityA
- entityB -> EntityB
- EntityB
When I fetch an EntityA, the relationship entityB is
initialited with an EOAccessDeferredFaultHandler
(takeStoredValueForKey) while the SQL select statement
returns 0 row.
When I try to access to the relationship entityB, it is
updated with an _EOVectorKeyGlobalID (takeStoredValueForKey).
But, I expected a null value. What's the problem?
Webobjects 5.2.4
MacOS X Tiger (I have the same behavior on X.3).
Frédéric
_______________________________________________
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