To be fair this depends on the kind of issue and on the user effort
to prove to the developers that a given fix is actually going to make
things better.
Andrus
On Jun 28, 2007, at 11:18 AM, Peter Schröder wrote:
> the speed of fixing things is amaizing... i wish that tapestry
> would have such a support!
>
> -----Ursprüngliche Nachricht-----
> Von: Andrus Adamchik [mailto:andru..bjectstyle.org]
> Gesendet: Donnerstag, 28. Juni 2007 10:11
> An: use..ayenne.apache.org
> Betreff: Re: paged query slow when fetching big lists
>
> Fixed. Now the things are fast on the client as well.
>
> Andrus
>
> On Jun 28, 2007, at 12:18 AM, Andrus Adamchik wrote:
>
>>
>> On Jun 27, 2007, at 6:38 AM, Marcin Skladaniec wrote:
>>
>>> There is one but: fix does work only for queries executed on
>>> server, when I executed the query on (ROP) client, the query takes
>>> the same amount of time ! Is it possible that the remote calls are
>>> using a different constructor ? or maybe the
>>> isFetchingCustomAttributes() returns true for 'remote'
>>> SelectQueries, and therefore the constructor works as before ?
>>
>> Doh! Yeah, I found the reason - client wraps paginated SelectQuery
>> in a IncrementalQuery wrapper (needed for server-side caching), and
>> the optimization code inside IncrementalFaultList is hardcoded to
>> look for SelectQuery. I don't have an immediate solution - I have
>> to think about it a bit, and test a few possibilities. But at least
>> we've identified the problem.
>>
>> Andrus
>>
>>
>
>
This archive was generated by hypermail 2.0.0 : Thu Jun 28 2007 - 05:04:55 EDT