cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Third prefetch kind - DISJOINT_BY_ID
Date Mon, 30 Jan 2012 12:14:52 GMT
Yes I envision the new strategy to be used for relatively small result sets. So I am not suggesting
we replace DISJOINT with this behind the scenes. I'd like to leave it up to the users to pick
(or maybe we can auto-choose based on the size of the main result set).

BTW paginated queries internally have a control limiting the size of the WHERE clause. It
is hardcoded inside IncrementalFaultList and the value is 10000. So any extra large IN query
will be broken to chunks.

> How do these solutions work when the user tries to order the results on something across
a to-one join?

Root query works the same with or without a disjoint prefetch, even if some joins overlap.
Ordering of related (prefetched or otherwise) objects is controlled by the user.

Andrus

On Jan 30, 2012, at 2:54 PM, Aristedes Maniatis wrote:
> On 30/01/12 10:43 PM, Andrus Adamchik wrote:
>>> And does DISJOINT map to:
>>> 
>>>  SELECT * FROM ARTIST WHERE ARTIST_NAME LIKE 'X%' FETCH LIMIT 10;
>>>  SELECT * FROM PAINTING WHERE true;
>> 
>> Effectively yes. With some extra nastiness like joins inherited from the parent query.
>> 
>>> Are you proposing this new join type be:
>>> 
>>>  SELECT * FROM ARTIST WHERE ARTIST_NAME LIKE 'X%' FETCH LIMIT 10;
>>>  SELECT * FROM PAINTING WHERE ARTIST_ID IN (123, 124, ....)
>> 
>> Yes.
>> 
>> Andrus
>> 
> 
> Some databases don't like the IN clause to be too big. 1024 entries seems to be in my
head about when we hit an error with MS SQL in the past.
> 
> How do these solutions work when the user tries to order the results on something across
a to-one join?
> 
> 
> 
> 
> 
> Ari
> 
> 
> 
> -- 
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
> 


Mime
View raw message