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: Peter Vandoros <email@hidden>
- Date: Wed, 13 May 2009 16:40:27 +1000
Hi Lachlan,
I've tested this on both 5.2 and 5.3. Haven't tried 5.4 yet.
Nothing weird in this scenario (ie. no inheritence and not cross-model
relationships).
Looking at the EODatabaseContext._fetchRawRowKeyPaths() method in a
"debugger", it definitely checks if there is at least one attribute of
the root entity (ie. the one being fetched agains;
fSpec.entityName()), it will add the foreign key to the relationship
from the root entity to the fetch attributes. I'm not sure why that
logic is there since the SQL it generates it valid.
Regards
Peter
On 13/05/2009, at 4:26 PM, Lachlan Deck wrote:
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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
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