> Ok, I think I should explain a little further. I'm using a third- party
> control (Trirand's jqgrid MVC control) which accepts an IQueryable<T>, and
> using Reflector have worked out that this is the kind of call they are
> making.
>
> I agree that doing a ToList() then Count() would give the correct result,
> and arguably this control should be rewritten to do this (since they are
> subsequently calling ToList() anyway). However I don't have access to
their
> code and besides it seems to me that just calling Count() should work as
> expected.
knowing that the DevExpress' grid with their linqdatasource creates
complex linq queries with much more complex issues than the one you posted,
(like grouping on a constant :)), it's inevitable to simply support these
constructs, otherwise people will simply not use the linq provider (and that
would be a waste of effort).
the query you reported is a valid linq query, it should produce the
query you expected, so I'd opt for filing a bug report, but it's up to Steve
(where's Steve anyway? ;)) if he has time to fix this.
The 'ToList()' workaround is silly really, you don't want to fetch
all data to do an aggregate in-memory
> Should I log this as a bug somewhere??
you can log issues here: http://216.121.112.228
FB
>
> Thanks very much for your replies.
>
> Alastair
>
>
>
>
>
> On Jul 23, 8:27 am, "Frans Bouma" <[email protected]> wrote:
> > > 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- Hide quoted text -
> >
> > - Show quoted text-
