[nhibernate-issues] [JIRA] Commented: (NH-860) Performant count of HQL query

[NHibernate J. <mik...@us...>]

    [ http://jira.nhibernate.org/browse/NH-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_15959 ] 

Fabio Maulo commented on NH-860:
--------------------------------

Probably we can implement a solution but is not a guarantee that it can work for any kind of queries.

Your "original" query can include <group by> <order by> and so on, we can do something to remove it before create the "count query".
If your query use some other clause (in a sub-sub-query) not accepted by the clause "count" we can't do something.

For this kind of issue I prefer to use named queries that are optimized to do the right work (the count is, normally, more simple than the original select).
The two queries are named, for example:
MyOriginalQuery
MyOriginalQuery.Count

Then I use the two query separately.

In http://unhaddins.googlecode.com/  you can see this solution for pagination.

Any way for a "partial" solution we can think a specific NH solution (I'm not secure that is a good idea)




> Performant count of HQL query
> -----------------------------
>
>                 Key: NH-860
>                 URL: http://jira.nhibernate.org/browse/NH-860
>             Project: NHibernate
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.2.0.Beta3
>            Reporter: Luis Ferreira
>            Priority: Major
>             Fix For: LATER
>
>
> We are implementing pagination in our Web Project and we'd like to have a way of calculating the count(*) for each of the HQL queries we have already implemented *without writing specific queries for that* AND *without returning the results as a list* and then getting its count property.
> A member of the team has attempted, with some success, to use NHibernate to
> generate the SQL for our HQL queries and then wrapping it with a select
> count(*) from (<generated SQL>). But to do that we have had to use
> Reflection to access protected methods, and filling query parameters for
> parametrized queries is still a problem. To really tackle the issue it would
> be necessary to have some changes in NHibernate, namely public exposure in
> IQuery of methods in AbstractQueryImpl / QueryImpl regarding access to named
> parameters names and values.
> Of course a really great solution would be for NHibernate to provide that
> count(*) funcionality (in a way similar to what has been done with
> projections for ICriteria? haven't used that much, we've got really hairy
> queries to write). It seems to be an issue for a lot of people. For
> databases that support subquerying it wouldn't be too difficult to
> implement I guess, but maybe the team doesn't want to impose that kind of
> restrictions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira