cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roman Zamorski" <>
Subject Re: ESQL and max-rows / skip-rows attributes
Date Thu, 25 Jan 2001 20:34:54 GMT

----- Original Message -----
From: "Donald Ball" <>
To: <>
Sent: Wednesday, January 24, 2001 12:25 AM
Subject: Re: ESQL and max-rows / skip-rows attributes

> On Tue, 23 Jan 2001, Roman Zamorski wrote:
> > > >By looking at the code, it seems that for each execution of a
> > > ><esql:connection> the underlying query is always executed. Only
> > > >insertion of the sql results into the current DOM tree the
> > > ><esql:max-rows> and <esql:skip-rows> are used to define the
range of
> > > >records (skip-rows, skip-rows + max-rows] to be inserted.
> > > >
> > > >As this can easily get very expensive for complex queries, I am
> > > >for an alternative way to 'cache' long results as returned by the
> >
> > there is also an alternative way of doing this by using of SQL 'LIMIT'
> > command.
> > LIMIT maxrows || LIMIT skiprows,maxrows
> > you can put it at the end of the query statement like this:
> >
> > select * from table limit 10,20;
> interesting, i've never used this clause (i don't work with huge datasets
> much). looks like there are a couple of caveats for some databases:
> "As of Postgres 7.0, the query optimizer takes LIMIT into account when
> generating a query plan, so you are very likely to get different plans
> (yielding different row orders) depending on what you give for LIMIT and
> OFFSET. Thus, using different LIMIT/OFFSET values to select different
> subsets of a query result will give inconsistent results unless you
> enforce a predictable result ordering with ORDER BY. This is not a bug; it
> is an inherent consequence of the fact that SQL does not promise to
> deliver the results of a query in any particular order unless ORDER BY is
> used to constrain the order."
> i could automatically tack on a LIMIT clause when max and/or skip rows are
> requested when working on databases we know to support this clause, but i
> fear that esql users who don't know of the ordering caveat may be
> surprised if this started happening. any suggestions?
hm... is there a way to REQUIRE a tag/attribute if some other is given to
some esql-tag? if yes you could do
esql:order-by tag, which would be required for esql:max-rows or


View raw message