> Nobody knows which is the real target of the query... well... nobody...
> perhaps the user knows.
> Wherever you put the Count() I can't understand the sense.
of course the real target is known: it's the result of the Take()
method. Skip & Take are query modifiers, not real query returning methods
('query' in the sense of a select statement). The source of skip is a query,
so skip & take modify that query and it then becomes the source of count.
Same sort of query:
session.Linq<Foo>().Count(c=>c.SomeField=="Bar");
here no skip/take is present, but as these are query modifiers, it's
not really a different construct: you have a query and it's used as the
source of the aggregate.
FB
>
>
> On Thu, Jul 22, 2010 at 3:20 PM, Frans Bouma <[email protected]> wrote:
>
>
> > I'm trying to perform this query on NHibernate 2.1.2 with
> NHibernate.Linq
> > (1.1.0.1001)
> >
> > session.Linq<FieldStructure>().Skip(10).Take(10).Count()
> >
> > This generates the following SQL
> >
> > "NHibernate: SELECT TOP 10 y0_ FROM (SELECT count(*) as y0_,
> > ROW_NUMBER() OVER(ORDER BY CURRENT_TIMESTAMP) as
> __hibernate_sort_row FROM
> > FieldStructure this_) as query WHERE query.__hibernate_sort_row >
> > 10 ORDER BY query.__hibernate_sort_row"
> >
> > This query always returns 0 rows, I know I should be getting 10
> rows.
> >
> > If I perform the same query without the Count(), I will get 10
> rows.
> > The SQL generated is...
> >
> > "NHibernate: SELECT TOP 10 <list of fields>, ROW_NUMBER()
> OVER(ORDER BY
> > CURRENT_TIMESTAMP) as __hibernate_sort_row FROM FieldStructure
> this_ left
> > outer join Lookup lookup2_ on
> > this_.LookupId=lookup2_.LookupId) as query WHERE
> query.__hibernate_sort_row
> > > 10 ORDER BY query.__hibernate_sort_row"
> >
> > Is this a bug?
>
>
> Looks like it. The link provider apparently sees the
aggregate
> expression as the outer query, but that shouldn't be done that way:
> the skip
> and take expressions are consumed by an expression visitor but the
> values
> they get as parameters should be applied to the query / sequence
they
> work
> on, and _that_ sequence is then the source of the aggregate
> expression,
> which always works on a separate scope, so it could never be wrapped
> by a
> take.
>
> FB
>
>
>
>
>
>
>
>
> --
> Fabio Maulo
>
