Re: AW: paged query slow when fetching big lists

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Thu Jun 28 2007 - 05:04:30 EDT

  • Next message: Jack O'Connor: "Re: getting started"

    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