Re: Standalone prefetch without main query?

At 09:22 AM 11/6/2002 +0000, John Pollard wrote:
>One of the problems with the batchFetchRelationship approach is that it is 
>built up with one OR per object in the NSArray passed to it. Am I right in 
>thinking that most databases will limit the number of ORs in an SQL 
>statement? In my case I happen to know the top level NSArray will not be 
>too large, but the second level (Companies in your example above) could 
>contain thousands of results.

True, that's a good point.  In the case of my own database, MS SQL Server, 
I believe the limit is around 3000.  So it's pretty high, but could 
sometimes be exceeded. You could write the code to batch the second-level 
fetch into groups of X, where X is the limit. (Ie, call the second-level 
batchFetchRelationship multiple times, with no more than X objects each 
time).  It's not ideal, and it's kind of a pain, but it's better than nothing.

>  When prefetching as part of a fetch spec some clever code bases the 
> query for Continents (in your example) on the criteria of the main query 
> for People, not requiring an OR for each Company returned. I wish 
> batchFetchRelationship() could be that clever.

Yes.  You can figure out how to write an appropriate fetch spec that will 
fetch the objects based on the joins, rather than a bunch of ORs.  The 
problem is getting the to-many relationship faults to be filled with these 
results, rather than remain faults that will go to the db upon fetch.

I messed around with this a little, a long time ago.  In WO4.5, I think I 
could get away with calling takeStoredValueForKey on an EOGenericRecord, 
with a to-many relationship as the key. The EO would then have my specified 
values as it's relationship, without ever going to the db itself. In WO5, 
however, I believe that takeStoredValueForKey will trigger willRead(), 
which will trip the fault resulting in a trip to the db, before your new 
values are even accepted.  I was never very comfortable with that solution 
anyway.

But if we could figure out how to tell a whole bunch of EOs: replace your 
to-many fault for relationship X with this array of objects---don't go to 
the db yourself... then we could write our own solution.


>John