|
From: NHibernate J. <mik...@us...> - 2007-10-17 05:41:59
|
[ http://jira.nhibernate.org/browse/NH-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_15972 ]
Fabio Maulo commented on NH-860:
--------------------------------
You are right Ayende...
That is the issue for my: "I'm not secure that is a good idea"
but have a TransformToRowCount for HQL queries is very interesting even if it can be throw and exception in some case of use... and more interesting now that we have QueryPlan because both queries can be parsed and cached together at sessionFactory build.
If Sergey, and others developers, approve I can work on this issue.
Probably we need to change:
IQueryTranslator
IQuery
xsd for namedQuery (to enable the parse for count)
> 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
|