Re: Unexpected EOF behaviour with raw row fetches... explanation anyone?
Re: Unexpected EOF behaviour with raw row fetches... explanation anyone?
- Subject: Re: Unexpected EOF behaviour with raw row fetches... explanation anyone?
- From: Lachlan Deck <email@hidden>
- Date: Wed, 13 May 2009 16:26:44 +1000
Hi Peter,
what version of WO are you using? Are you using Wonder?
There was a regression in WO5.4 about entity parents/roots resolving
(so if you're using anything other than single table inheritance or
cross-model relations you'd get bad results). If you're not using
Wonder I supplied some fixes already to the known issues I had.
If you're using WO5.3 - then .. hmm.
On 13/05/2009, at 1:57 PM, Peter Vandoros wrote:
I have come across some unexpected EOF behaviour [1] that I need
some explanation of.
The basic unexpected behaviour is as follows:
EOF will automatically add an additional attribute to fetch to a raw
row fetch that doesn't include any attributes of the root entity
being fetched. This can lead to incorrect results, in particular
when using "fSpec.setUsesDistinct(true)".
I traced this behaviour down to the
EODatabaseContext
._fetchRawRowKeyPaths(NSArray,EOFetchSpecification,EOEntity,
EOEditingContext) method checking if at least one attribute of the
root entity is included in the rawRowKeyPaths. If there isn't one,
it will get the last rawRowKeyPath and add the sourceAttribute of
the relationship returned from
"firstComponentFromRelationshipPath(rawRowKeyPath)" to the fetch.
The example below demonstrates this behaviour when I attempt to get
a distinct list of countries from users in a group. That is, I wish
to limit the list of countries to those from which any member of the
group is located.
An example:
Model:
Group < --->> GroupMembership <<---> User <---> UserDetails
Relevant attributes and relationships:
GroupMembership
Attributes:
- groupId (foreign key to Group)
- userId (foreign ket to User)
- other attributes ...
Relationships:
- user (to-one to User)
- group (to-one to Group)
- other relationships ...
User
Relationships:
- userDetails (to-one to UserDetails)
UserDetails
Attributes:
- country
- state
- etc...
Fetch details:
Entity name: GroupMembership [2]
Qualifier: "((groupId = 124) and (user.userDetails.country is not
null))"
Fetches raw rows: true
Raw row key paths: ("user.userDetails.country")
Uses distinct: true
Data:
7 users located in three different countries (Australia, Canada, and
New Zealand) that are members of the group (id:124).
Expected results:
A list of countries from which any member of the group is located
_without any_ duplicate entries and _only one_ attribute in the
fetch results.
Example raw rows:
-> {user.userDetails.country = "Australia";}
-> {user.userDetails.country = "Canada";}
-> {user.userDetails.country = "New Zealand";}
Actual results:
A list of countries from which any member of the group is located
_with_ duplicate entries and _an additional_ attribute in the fetch
results.
Example raw rows:
-> {user.userDetails.country = "Australia"; userId = 1;}
-> {user.userDetails.country = "Australia"; userId = 2;}
-> {user.userDetails.country = "Canada"; userId = 3;}
-> {user.userDetails.country = "Australia"; userId = 4;}
-> {user.userDetails.country = "Canada"; userId = 5;}
-> {user.userDetails.country = "Australia"; userId = 6;}
-> {user.userDetails.country = "New Zealand"; userId = 7;}
I hope this makes sense?
[1] Hence why I submitted a bug to Apple (#6882157)
[2] I know I can achieve the same thing without this unexpected
behaviour if fetch against UserDetails instead of GroupMembership. I
am fetching against GroupMembership as it is more efficient for the
SQL query to perform 2 to-one joins instead of 1 to-one join and 1
to-many join. In my case, the model is a little bit more complicated
and the joins performed are actually 1 to-one join and 2 to-many
joins.
Regards
Peter Vandoros
Software Engineer
Etech Group Pty Ltd
Level 3/21 Victoria St
Melbourne VIC 3000
Australia
Ph: +61 3 9639 9677
Fax: +61 3 9639 9577
----------------------------------
IMPORTANT: This e-mail message and any attachments are confidential
and may be privileged. If received in error, please reply to this
message and destroy all copies and any attachments. You should check
this message and any attachments for viruses or defects. Our
liability is limited to resupplying any affected message or
attachments. For more information about Etech Group, please visit us
at http://www.etechgroup.com.au.
_______________________________________________
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
with regards,
--
Lachlan Deck
_______________________________________________
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