nhibernate-issues — Updates to JIRA issues are sent to this list

[nhibernate-issues] [NHJIRA] Commented: (NH-2214) Distinct and Row_number problem

[Julian M. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21316#action_21316 ] 

Julian Maughan commented on NH-2214:
------------------------------------

I've spent additional time on this issue, and reached a reasonable solution. A patch for the current code-line is attached, and I will ask Fabio to review it to see if it can be included in 3.2.

The solution I'm putting forward is to only use the improved paging query when necessary; i.e. only when the statement to be 'paged' is a SELECT DISTINCT statement. Non-distinct queries use the current SQL. There is still an edge case that fails: a query with distinct results, and ordered by a non-projected/selected column. It fails because SQL Server can't handle 'ROW_NUMBER() OVER(ORDER BY column1)' if 'column1' isn't in the query's SELECT list - it is the scenario I explained above. On a positive note, my code checks for this case and an exception is thrown to explain the reason.

> Distinct and Row_number problem
> -------------------------------
>
>                 Key: NH-2214
>                 URL: http://216.121.112.228/browse/NH-2214
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: DataProviders / Dialects
>    Affects Versions: 2.1.1.GA, 2.1.2.GA
>            Reporter: Carlos Martinez
>            Assignee: Julian Maughan
>            Priority: Major
>         Attachments: MsSql2005Dialect.cs, NH-2214-reproduction.zip, NH-2214.patch, NH-2214.patch, NH-2214.zip
>
>
> Microsoft.NET Framework 3.5
> MSSQL 2008
> Select distinct T.ID, T.Name from T
> inner join T2 on T.ID = T2.TID
> order by T.Name
> With this native query (using ISQLQuery) and the statement "DISTINCT" is necessary because the union wiht T2 produces duplicate results of T. 
> if I use
> SetFirstResult(index)
> SetMaxResults(max)
> It generates the following Query
> Select top max
>   ID,
>   Name  
>   from
>         (select distinct
>           ID,
>           Name,
>           ROW_NUMBER () over (order by T.Name) as __hibernate_sort_row
>           from T
>           inner join T2) as query
>     where __hibernate_sort_row > index
> first results are generated with ROW_NUMER, for example
> T.ID  T.Name   __hibernate_sort_row
> 2     Carlos   1
> 1     Juan     2
> 1     Juan     3
> 3     Paulina  4
> 4     Zunio    5
> 4     Zunio    6
> 4     Zunio    7
> Then "DISTINCT" no longer makes sense, because all records are different due to ROW_NUMBER.
> In version 2.0.1 GA works perfectly

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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2773) ProxyObjectReference creates a new ProxyFactory for each deserialization which disables proxy caching

[cremor (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21315#action_21315 ] 

cremor commented on NH-2773:
----------------------------

Just tried to test that but I could only reach a ProxyFactoryFactory (and not the ProxyFactory itself) via the BytecodeProvider. But it seems like you have fixed it differently now?

> ProxyObjectReference creates a new ProxyFactory for each deserialization which disables proxy caching
> -----------------------------------------------------------------------------------------------------
>
>                 Key: NH-2773
>                 URL: http://216.121.112.228/browse/NH-2773
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: ByteCode providers
>    Affects Versions: 3.2.0Beta1
>            Reporter: cremor
>            Priority: Major
>             Fix For: 3.2.0CR1
>
>         Attachments: NH2773 Test.zip
>
>
> If you deserialize a session which contains references to proxies a new ProxyFactory (and thus ProxyCache) is created for each reference which results in a new proxy assembly and module for each reference.
> I think this class should also use the static ProxyFactory field of the DefaultProxyFactory so the cache is correctly used. A test for this assumption is attached.

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

        

[nhibernate-issues] [NHJIRA] Resolved: (NH-2773) ProxyObjectReference creates a new ProxyFactory for each deserialization which disables proxy caching

[Fabio M. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fabio Maulo resolved NH-2773.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 3.2.0CR1

> ProxyObjectReference creates a new ProxyFactory for each deserialization which disables proxy caching
> -----------------------------------------------------------------------------------------------------
>
>                 Key: NH-2773
>                 URL: http://216.121.112.228/browse/NH-2773
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: ByteCode providers
>    Affects Versions: 3.2.0Beta1
>            Reporter: cremor
>            Priority: Major
>             Fix For: 3.2.0CR1
>
>         Attachments: NH2773 Test.zip
>
>
> If you deserialize a session which contains references to proxies a new ProxyFactory (and thus ProxyCache) is created for each reference which results in a new proxy assembly and module for each reference.
> I think this class should also use the static ProxyFactory field of the DefaultProxyFactory so the cache is correctly used. A test for this assumption is attached.

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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2773) ProxyObjectReference creates a new ProxyFactory for each deserialization which disables proxy caching

[Fabio M. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21314#action_21314 ] 

Fabio Maulo commented on NH-2773:
---------------------------------

The test fail even with static ProxyFactory.
The DefaultProxyFactory is part of the BytecodeProvider (static in Environment)

> ProxyObjectReference creates a new ProxyFactory for each deserialization which disables proxy caching
> -----------------------------------------------------------------------------------------------------
>
>                 Key: NH-2773
>                 URL: http://216.121.112.228/browse/NH-2773
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: ByteCode providers
>    Affects Versions: 3.2.0Beta1
>            Reporter: cremor
>            Priority: Major
>         Attachments: NH2773 Test.zip
>
>
> If you deserialize a session which contains references to proxies a new ProxyFactory (and thus ProxyCache) is created for each reference which results in a new proxy assembly and module for each reference.
> I think this class should also use the static ProxyFactory field of the DefaultProxyFactory so the cache is correctly used. A test for this assumption is attached.

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

        

[nhibernate-issues] [NHJIRA] Resolved: (NH-2774) Perf - reusing same regex object in joinwalker objects

[Fabio M. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fabio Maulo resolved NH-2774.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 3.2.0CR1

> Perf - reusing same regex object in joinwalker objects
> ------------------------------------------------------
>
>                 Key: NH-2774
>                 URL: http://216.121.112.228/browse/NH-2774
>             Project:  NHibernate
>          Issue Type: Patch
>          Components: Core
>    Affects Versions: 3.2.0Beta2
>            Reporter: Roger
>            Priority: Minor
>             Fix For: 3.2.0CR1
>
>         Attachments: joinwalkerRegexPerf.patch, perfRegExStatic.PNG
>
>
> When upgrading, my test suite took approx 17% longer to run (most of the overhead time spent when building session factory). This was caused when creating regex objects in joinwalker. Now reusing same instance instead, the overhead is gone.
> Adding snippet from dotTrace as attachment.

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

        

[nhibernate-issues] [NHJIRA] Created: (NH-2774) Perf - reusing same regex object in joinwalker objects

[Roger (JIRA) <nh...@gm...>]

Perf - reusing same regex object in joinwalker objects
------------------------------------------------------

                 Key: NH-2774
                 URL: http://216.121.112.228/browse/NH-2774
             Project:  NHibernate
          Issue Type: Patch
          Components: Core
    Affects Versions: 3.2.0Beta2
            Reporter: Roger
            Priority: Minor
         Attachments: joinwalkerRegexPerf.patch, perfRegExStatic.PNG

When upgrading, my test suite took approx 17% longer to run (most of the overhead time spent when building session factory). This was caused when creating regex objects in joinwalker. Now reusing same instance instead, the overhead is gone.

Adding snippet from dotTrace as attachment.

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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2773) ProxyObjectReference creates a new ProxyFactory for each deserialization which disables proxy caching

[cremor (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21313#action_21313 ] 

cremor commented on NH-2773:
----------------------------

I just saw that in Beta2 the ProxyFactory field of the DefaultProxyFactory isn't static any more. I don't know if the DefaultProxyFactory itself is cached anywhere but if not my test will of course fail even after the fix (and I'd then also wonder how the proxy caching works at all).

> ProxyObjectReference creates a new ProxyFactory for each deserialization which disables proxy caching
> -----------------------------------------------------------------------------------------------------
>
>                 Key: NH-2773
>                 URL: http://216.121.112.228/browse/NH-2773
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: ByteCode providers
>    Affects Versions: 3.2.0Beta1
>            Reporter: cremor
>            Priority: Major
>         Attachments: NH2773 Test.zip
>
>
> If you deserialize a session which contains references to proxies a new ProxyFactory (and thus ProxyCache) is created for each reference which results in a new proxy assembly and module for each reference.
> I think this class should also use the static ProxyFactory field of the DefaultProxyFactory so the cache is correctly used. A test for this assumption is attached.

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

        

[nhibernate-issues] [NHJIRA] Updated: (NH-2761) SchemaUpdate Generates Additional Relations Mandatory on Both Endpoints

[Fabio M. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fabio Maulo updated NH-2761:
----------------------------

    Component/s:     (was: Tests)
                 Toolset

> SchemaUpdate Generates Additional Relations Mandatory on Both Endpoints
> -----------------------------------------------------------------------
>
>                 Key: NH-2761
>                 URL: http://216.121.112.228/browse/NH-2761
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Toolset
>    Affects Versions: 3.2.0Beta1
>            Reporter: Ricardo Peres
>         Attachments: bd.png, NHTest.zip
>
>
> SchemaUpdate generates invalid schema. Additional relations, mandatory on both sides, are added to the following mapping (also attached), please see the attached picture:
> <hibernate-mapping default-lazy="false" namespace="NHTest" assembly="NHTest" xmlns="urn:nhibernate-mapping-2.2">
> 	<class name="A" lazy="false" table="`A`">
> 		<id name="Id" access="property" column="`A_ID`">
> 			<generator class="hilo" />
> 		</id>
> 		<property name="AProperty" column="`A_PROPERTY`" length="50"/>
> 		<many-to-one name="B" class="B" column="`B_ID`" not-null="false" />
> 		<many-to-one name="C" class="C" column="`C_ID`" not-null="false" />
> 	</class>
> </hibernate-mapping>
> <hibernate-mapping default-lazy="false" namespace="NHTest" assembly="NHTest" xmlns="urn:nhibernate-mapping-2.2">
> 	<class name="B" lazy="false" table="`B`">
> 		<id name="Id" access="property" column="`B_ID`">
> 			<generator class="hilo" />
> 		</id>
> 		<property name="BProperty" column="`B_PROPERTY`" length="50"/>
> 		<set name="As" inverse="true">
> 			<key column="`B_ID`"/>
> 			<one-to-many class="A"/>
> 		</set>
> 		<many-to-one name="C" class="C" column="`C_ID`" not-null="false" fetch="select"/>
> 	</class>
> </hibernate-mapping>
> <hibernate-mapping default-lazy="false" namespace="NHTest" assembly="NHTest" xmlns="urn:nhibernate-mapping-2.2">
> 	<class name="C" lazy="false" table="`C`">
> 		<id name="Id" access="property" column="`C_ID`">
> 			<generator class="hilo" />
> 		</id>
> 		<property name="CProperty" column="`C_PROPERTY`" length="50"/>
> 		<set name="As" inverse="true">
> 			<key column="`A_ID`"/>
> 			<one-to-many class="A"/>
> 		</set>
> 		<set name="Bs" inverse="true">
> 			<key column="`B_ID`"/>
> 			<one-to-many class="B"/>
> 		</set>
> 	</class>
> </hibernate-mapping>
> A test case is included which only generates the schema.

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

        

[nhibernate-issues] [NHJIRA] Updated: (NH-2773) ProxyObjectReference creates a new ProxyFactory for each deserialization which disables proxy caching

[cremor (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

cremor updated NH-2773:
-----------------------

    Attachment: NH2773 Test.zip

> ProxyObjectReference creates a new ProxyFactory for each deserialization which disables proxy caching
> -----------------------------------------------------------------------------------------------------
>
>                 Key: NH-2773
>                 URL: http://216.121.112.228/browse/NH-2773
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: ByteCode providers
>    Affects Versions: 3.2.0Beta1
>            Reporter: cremor
>            Priority: Major
>         Attachments: NH2773 Test.zip
>
>
> If you deserialize a session which contains references to proxies a new ProxyFactory (and thus ProxyCache) is created for each reference which results in a new proxy assembly and module for each reference.
> I think this class should also use the static ProxyFactory field of the DefaultProxyFactory so the cache is correctly used. A test for this assumption is attached.

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

        

[nhibernate-issues] [NHJIRA] Created: (NH-2773) ProxyObjectReference creates a new ProxyFactory for each deserialization which disables proxy caching

[cremor (JIRA) <nh...@gm...>]

ProxyObjectReference creates a new ProxyFactory for each deserialization which disables proxy caching
-----------------------------------------------------------------------------------------------------

                 Key: NH-2773
                 URL: http://216.121.112.228/browse/NH-2773
             Project:  NHibernate
          Issue Type: Bug
          Components: ByteCode providers
    Affects Versions: 3.2.0Beta1
            Reporter: cremor
            Priority: Major


If you deserialize a session which contains references to proxies a new ProxyFactory (and thus ProxyCache) is created for each reference which results in a new proxy assembly and module for each reference.
I think this class should also use the static ProxyFactory field of the DefaultProxyFactory so the cache is correctly used. A test for this assumption is attached.

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

        

[nhibernate-issues] [NHJIRA] Closed: (NH-2360) Projection Criteria Query ordered by SubQuery fails with paging in SqlServer 2005 "Must declare the scalar variable "@p1"."

[Fabio M. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fabio Maulo closed NH-2360.
---------------------------

    Resolution: Obsolete

> Projection Criteria Query ordered by SubQuery fails with paging in SqlServer 2005 "Must declare the scalar variable "@p1"."
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: NH-2360
>                 URL: http://216.121.112.228/browse/NH-2360
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.1.2.GA
>            Reporter: Josh Robb
>            Priority: Major
>
> Using Ayende's Blog sample from http://github.com/ayende/nhibernate-blog-model (need to make sure that the dialect is MsSql2005Dialect). 
> Executing the following query: 
>             var commentCount = DetachedCriteria.For<Comment>("c")
>                 .Add(Restrictions.Gt("c.id", 0))
>                 .Add(Restrictions.EqProperty("c.Post.id", "p.id"))
>                 .SetProjection(Projections.RowCount());
>             var criteria = DetachedCriteria.For<Post>("p")
>                 .SetProjection(Projections.ProjectionList()
>                     .Add(Projections.Property("Id"), "Id")
>                     .Add(Projections.Property("Title"), "Title")
>                     .Add(Projections.SubQuery(commentCount), "CommentCount"))
>                 .SetResultTransformer(Transformers.AliasToBean<PostsWithCount>())
>                 .AddOrder(new Order("CommentCount", false))
>                 .SetMaxResults(10)
>                 .SetFirstResult(10);
> Results in:
> NHibernate.ADOException: could not execute query
> [ SELECT TOP 10 y0_, y1_, y2_ FROM (SELECT this_.Id as y0_, this_.Title as y1_,(SELECT count(*) as y0_ FROM Comments this_0_ WHERE this_0_.Id > @p0 and this_0_.PostId = this_.Id) as y2_, ROW_NUMBER() OVER(ORDER BY (SELECT count(*) as y0_ FROM Comments this_0_ WHERE this_0_.Id > @p1 and this_0_.PostId = this_.Id) DESC) as __hibernate_sort_row FROM Posts this_) as query WHERE query.__hibernate_sort_row > 10 ORDER BY query.__hibernate_sort_row ]
> Positional parameters:  #0>0
> [SQL: SELECT TOP 10 y0_, y1_, y2_ FROM (SELECT this_.Id as y0_, this_.Title as y1_, (SELECT count(*) as y0_ FROM Comments this_0_ WHERE this_0_.Id > @p0 and this_0_.PostId = this_.Id) as y2_, ROW_NUMBER() OVER(ORDER BY (SELECT count(*) as y0_ FROM Comments this_0_ WHERE this_0_.Id > @p1 and this_0_.PostId = this_.Id) DESC) as __hibernate_sort_row FROM Posts this_) as query WHERE query.__hibernate_sort_row > 10 ORDER BY query.__hibernate_sort_row]
> ---> System.Data.SqlClient.SqlException: Must declare the scalar variable "@p1".
>    at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
>    at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
>    at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
>    at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
>    at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
>    at System.Data.SqlClient.SqlDataReader.get_MetaData()
>    at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
>    at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
>    at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
>    at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
>    at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
>    at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
>    at System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader()
>    at NHibernate.AdoNet.AbstractBatcher.ExecuteReader(IDbCommand cmd)
>    at NHibernate.Loader.Loader.GetResultSet(IDbCommand st, Boolean autoDiscoverTypes, Boolean callable, RowSelection selection, ISessionImplementor session)
>    at NHibernate.Loader.Loader.DoQuery(ISessionImplementor session, QueryParameters queryParameters, Boolean returnProxies)
>    at NHibernate.Loader.Loader.DoQueryAndInitializeNonLazyCollections(ISessionImplementor session, QueryParameters queryParameters, Boolean returnProxies)
>    at NHibernate.Loader.Loader.DoList(ISessionImplementor session, QueryParameters queryParameters)
>    --- End of inner exception stack trace ---
>    at NHibernate.Loader.Loader.DoList(ISessionImplementor session, QueryParameters queryParameters)
>    at NHibernate.Loader.Loader.ListIgnoreQueryCache(ISessionImplementor session, QueryParameters queryParameters)
>    at NHibernate.Loader.Loader.List(ISessionImplementor session, QueryParameters queryParameters, ISet`1 querySpaces, IType[] resultTypes)
>    at NHibernate.Impl.SessionImpl.List(CriteriaImpl criteria, IList results)
>    at NHibernate.Impl.CriteriaImpl.List(IList results)
>    at NHibernate.Impl.CriteriaImpl.List[T]()
>    at CreateUpdateDDL.Program.Main(String[] args) in C:\dev\Advanced.NHibernate\CreateUpdateDDL\Program.cs:line 55

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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2693) Queries with nested subqueries either fail or return wrong results

[cremor (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21312#action_21312 ] 

cremor commented on NH-2693:
----------------------------

Ups, sorry about the mapping error in query 5 and 6. That's the result of using Fluent NHibernate usually and XML only for NHibernate bugs ;)

About the lists: I know that they behave differently as sets (for transient entities) but other than that it shoudn't cause any problems, right?

> Queries with nested subqueries either fail or return wrong results
> ------------------------------------------------------------------
>
>                 Key: NH-2693
>                 URL: http://216.121.112.228/browse/NH-2693
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.2.0Alpha2
>            Reporter: cremor
>            Priority: Major
>         Attachments: NH2693 Test.zip
>
>
> The attached test shows multiple failing queries which have in common that they are all using nested subqueries. I have no idea if the different queries fail because of different bugs or if it's all because of the same, but I hope they are clear enough that they can be fixed.
> Following is an explanation of the test:
> Domain model:
> FirstLevel has a set of components of type SecondLevelComponent.
> SecondLevelComponent has a many-to-one to ThirdLevel.
> ThirdLevel is the abstract base of SpecificThirdLevel (table-per-subclass mapping).
> SpecificThirdLevel has a set of entities of type FourthLevel.
> The queries and why they are failing:
> * _1_Querying_BasedOnFourthLevelExistence_WithIsAndCasting_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select all FirstLevel entities that have at least one FourthLevel entity as child, implemented by using the "is" operator and then casting the ThirdLevel to a SpecificThirdLevel.
> - Returns wrong results, the generated SQL checks for existing ThirdLevel childs instead of FourthLevel childs.
> * _2_Querying_BasedOnFourthLevelExistence_WithSelectAndOfType_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select same as first query, but this time implemented by using the Select() and OfType() methods.
> - Fails with exception "QueryException : could not resolve property: class of: component[ThirdLevel,SpecificThirdLevel,SomeBool]". I think it should check the class of ThirdLevel instead of SecondLevelComponent.
> * _3_Querying_BasedOnFourthLevelProperty_WithIsAndCasting_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select all FirstLevel entities that have at least one FourthLevel entity _with a specific property_ as child. Implemented with "is" and casting like the first query.
> - Fails with exception "QueryException : could not resolve property: SomeString of: ThirdLevel". It should search the "SomeString" property on FourthLevel instead of ThirdLevel.
> * _4_Querying_BasedOnFourthLevelProperty_WithSelectAndOfType_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select same as third query, but this time implemented with Select() and OfType() like the second query.
> - Fails with same exception as the second query.
> The last two queries are not using a polymorphistic association. Instead they are using the property SecondLevelComponent.SpecificThirdLevel so that no type checking or casting is needed. But they are still failing:
> * _5_Querying_BasedOnFourthLevelExistence_ByUsingSpecificThirdLevelProperty_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select same as first and second query.
> - Returns no entities. But I'm not sure why it doesn't return anything.
> * _6_Querying_BasedOnFourthLevelProperty_ByUsingSpecificThirdLevelProperty_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select same as third and fourth query.
> - Also returns no entities and I also don't know why.

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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2693) Queries with nested subqueries either fail or return wrong results

[Fabio M. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21311#action_21311 ] 

Fabio Maulo commented on NH-2693:
---------------------------------

Tests committed

> Queries with nested subqueries either fail or return wrong results
> ------------------------------------------------------------------
>
>                 Key: NH-2693
>                 URL: http://216.121.112.228/browse/NH-2693
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.2.0Alpha2
>            Reporter: cremor
>            Priority: Major
>         Attachments: NH2693 Test.zip
>
>
> The attached test shows multiple failing queries which have in common that they are all using nested subqueries. I have no idea if the different queries fail because of different bugs or if it's all because of the same, but I hope they are clear enough that they can be fixed.
> Following is an explanation of the test:
> Domain model:
> FirstLevel has a set of components of type SecondLevelComponent.
> SecondLevelComponent has a many-to-one to ThirdLevel.
> ThirdLevel is the abstract base of SpecificThirdLevel (table-per-subclass mapping).
> SpecificThirdLevel has a set of entities of type FourthLevel.
> The queries and why they are failing:
> * _1_Querying_BasedOnFourthLevelExistence_WithIsAndCasting_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select all FirstLevel entities that have at least one FourthLevel entity as child, implemented by using the "is" operator and then casting the ThirdLevel to a SpecificThirdLevel.
> - Returns wrong results, the generated SQL checks for existing ThirdLevel childs instead of FourthLevel childs.
> * _2_Querying_BasedOnFourthLevelExistence_WithSelectAndOfType_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select same as first query, but this time implemented by using the Select() and OfType() methods.
> - Fails with exception "QueryException : could not resolve property: class of: component[ThirdLevel,SpecificThirdLevel,SomeBool]". I think it should check the class of ThirdLevel instead of SecondLevelComponent.
> * _3_Querying_BasedOnFourthLevelProperty_WithIsAndCasting_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select all FirstLevel entities that have at least one FourthLevel entity _with a specific property_ as child. Implemented with "is" and casting like the first query.
> - Fails with exception "QueryException : could not resolve property: SomeString of: ThirdLevel". It should search the "SomeString" property on FourthLevel instead of ThirdLevel.
> * _4_Querying_BasedOnFourthLevelProperty_WithSelectAndOfType_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select same as third query, but this time implemented with Select() and OfType() like the second query.
> - Fails with same exception as the second query.
> The last two queries are not using a polymorphistic association. Instead they are using the property SecondLevelComponent.SpecificThirdLevel so that no type checking or casting is needed. But they are still failing:
> * _5_Querying_BasedOnFourthLevelExistence_ByUsingSpecificThirdLevelProperty_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select same as first and second query.
> - Returns no entities. But I'm not sure why it doesn't return anything.
> * _6_Querying_BasedOnFourthLevelProperty_ByUsingSpecificThirdLevelProperty_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select same as third and fourth query.
> - Also returns no entities and I also don't know why.

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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2693) Queries with nested subqueries either fail or return wrong results

[Fabio M. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21310#action_21310 ] 

Fabio Maulo commented on NH-2693:
---------------------------------

For the others we have to check.
btw... you can't map a List<T> to a <set>

> Queries with nested subqueries either fail or return wrong results
> ------------------------------------------------------------------
>
>                 Key: NH-2693
>                 URL: http://216.121.112.228/browse/NH-2693
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.2.0Alpha2
>            Reporter: cremor
>            Priority: Major
>         Attachments: NH2693 Test.zip
>
>
> The attached test shows multiple failing queries which have in common that they are all using nested subqueries. I have no idea if the different queries fail because of different bugs or if it's all because of the same, but I hope they are clear enough that they can be fixed.
> Following is an explanation of the test:
> Domain model:
> FirstLevel has a set of components of type SecondLevelComponent.
> SecondLevelComponent has a many-to-one to ThirdLevel.
> ThirdLevel is the abstract base of SpecificThirdLevel (table-per-subclass mapping).
> SpecificThirdLevel has a set of entities of type FourthLevel.
> The queries and why they are failing:
> * _1_Querying_BasedOnFourthLevelExistence_WithIsAndCasting_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select all FirstLevel entities that have at least one FourthLevel entity as child, implemented by using the "is" operator and then casting the ThirdLevel to a SpecificThirdLevel.
> - Returns wrong results, the generated SQL checks for existing ThirdLevel childs instead of FourthLevel childs.
> * _2_Querying_BasedOnFourthLevelExistence_WithSelectAndOfType_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select same as first query, but this time implemented by using the Select() and OfType() methods.
> - Fails with exception "QueryException : could not resolve property: class of: component[ThirdLevel,SpecificThirdLevel,SomeBool]". I think it should check the class of ThirdLevel instead of SecondLevelComponent.
> * _3_Querying_BasedOnFourthLevelProperty_WithIsAndCasting_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select all FirstLevel entities that have at least one FourthLevel entity _with a specific property_ as child. Implemented with "is" and casting like the first query.
> - Fails with exception "QueryException : could not resolve property: SomeString of: ThirdLevel". It should search the "SomeString" property on FourthLevel instead of ThirdLevel.
> * _4_Querying_BasedOnFourthLevelProperty_WithSelectAndOfType_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select same as third query, but this time implemented with Select() and OfType() like the second query.
> - Fails with same exception as the second query.
> The last two queries are not using a polymorphistic association. Instead they are using the property SecondLevelComponent.SpecificThirdLevel so that no type checking or casting is needed. But they are still failing:
> * _5_Querying_BasedOnFourthLevelExistence_ByUsingSpecificThirdLevelProperty_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select same as first and second query.
> - Returns no entities. But I'm not sure why it doesn't return anything.
> * _6_Querying_BasedOnFourthLevelProperty_ByUsingSpecificThirdLevelProperty_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select same as third and fourth query.
> - Also returns no entities and I also don't know why.

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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2693) Queries with nested subqueries either fail or return wrong results

[Fabio M. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21309#action_21309 ] 

Fabio Maulo commented on NH-2693:
---------------------------------

5 and 6 fails because wrong mapping.

> Queries with nested subqueries either fail or return wrong results
> ------------------------------------------------------------------
>
>                 Key: NH-2693
>                 URL: http://216.121.112.228/browse/NH-2693
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.2.0Alpha2
>            Reporter: cremor
>            Priority: Major
>         Attachments: NH2693 Test.zip
>
>
> The attached test shows multiple failing queries which have in common that they are all using nested subqueries. I have no idea if the different queries fail because of different bugs or if it's all because of the same, but I hope they are clear enough that they can be fixed.
> Following is an explanation of the test:
> Domain model:
> FirstLevel has a set of components of type SecondLevelComponent.
> SecondLevelComponent has a many-to-one to ThirdLevel.
> ThirdLevel is the abstract base of SpecificThirdLevel (table-per-subclass mapping).
> SpecificThirdLevel has a set of entities of type FourthLevel.
> The queries and why they are failing:
> * _1_Querying_BasedOnFourthLevelExistence_WithIsAndCasting_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select all FirstLevel entities that have at least one FourthLevel entity as child, implemented by using the "is" operator and then casting the ThirdLevel to a SpecificThirdLevel.
> - Returns wrong results, the generated SQL checks for existing ThirdLevel childs instead of FourthLevel childs.
> * _2_Querying_BasedOnFourthLevelExistence_WithSelectAndOfType_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select same as first query, but this time implemented by using the Select() and OfType() methods.
> - Fails with exception "QueryException : could not resolve property: class of: component[ThirdLevel,SpecificThirdLevel,SomeBool]". I think it should check the class of ThirdLevel instead of SecondLevelComponent.
> * _3_Querying_BasedOnFourthLevelProperty_WithIsAndCasting_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select all FirstLevel entities that have at least one FourthLevel entity _with a specific property_ as child. Implemented with "is" and casting like the first query.
> - Fails with exception "QueryException : could not resolve property: SomeString of: ThirdLevel". It should search the "SomeString" property on FourthLevel instead of ThirdLevel.
> * _4_Querying_BasedOnFourthLevelProperty_WithSelectAndOfType_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select same as third query, but this time implemented with Select() and OfType() like the second query.
> - Fails with same exception as the second query.
> The last two queries are not using a polymorphistic association. Instead they are using the property SecondLevelComponent.SpecificThirdLevel so that no type checking or casting is needed. But they are still failing:
> * _5_Querying_BasedOnFourthLevelExistence_ByUsingSpecificThirdLevelProperty_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select same as first and second query.
> - Returns no entities. But I'm not sure why it doesn't return anything.
> * _6_Querying_BasedOnFourthLevelProperty_ByUsingSpecificThirdLevelProperty_ShouldReturnSameEntitiesAsLinqToObjects
> + Should select same as third and fourth query.
> - Also returns no entities and I also don't know why.

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

        

[nhibernate-issues] [NHJIRA] Resolved: (NH-2746) Invalid SQL generated for MSSQL when using Filter and paging subquery together [regression from 2.1]

[Fabio M. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fabio Maulo resolved NH-2746.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 3.2.0Beta2

As said ;)

> Invalid SQL generated for MSSQL when using Filter and paging subquery together [regression from 2.1]
> ----------------------------------------------------------------------------------------------------
>
>                 Key: NH-2746
>                 URL: http://216.121.112.228/browse/NH-2746
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Pete Appleton
>            Priority: Major
>             Fix For: 3.2.0Beta2
>
>         Attachments: NHTest.zip, QueryParams.patch
>
>
> On MS SQL Server 2005/2008, creating an ICriteria for a parent table with a join onto a child table and a paging subquery fails with a SQL exception if a filter is applied to the collection in the mapping and then enabled in code.  If the filter is not enabled then the query functions as expected.
> There's a very small test project provided to illustrate the problem; unfortunately, I've been unable to create a unit test using the template as I'm getting an error ["Could not find the dialect in the configuration"]; there is also a patch which appears to correct the problem, but it has not been subjected to the unit test suite.
> NHibernate exception details:
> NHibernate.Exceptions.GenericADOException: could not execute query
> [ SELECT this_.Id as Id0_1_, this_.Name as Name0_1_, children2_.T1Id as T3_3_, children2_.Id as Id3_, children2_.Id as Id1_0_, children2_.Name as Name1_0_, children2_.T1Id as T3_1_0_ FROM dbo.T1 this_ left outer join dbo.T2 children2_ on this_.Id=children2_.T1Id and @p0=children2_.Name WHERE this_.Id in (SELECT TOP (@p1) y0_ FROM (SELECT this_0_.Id as y0_, ROW_NUMBER() OVER(ORDER BY this_0_.Id) as __hibernate_sort_row FROM dbo.T1 this_0_) as query WHERE query.__hibernate_sort_row > @p2 ORDER BY query.__hibernate_sort_row) ]
> [SQL: SELECT this_.Id as Id0_1_, this_.Name as Name0_1_, children2_.T1Id as T3_3_, children2_.Id as Id3_, children2_.Id as Id1_0_, children2_.Name as Name1_0_, children2_.T1Id as T3_1_0_ FROM dbo.T1 this_ left outer join dbo.T2 children2_ on this_.Id=children2_.T1Id and @p0=children2_.Name WHERE this_.Id in (SELECT TOP (@p1) y0_ FROM (SELECT this_0_.Id as y0_, ROW_NUMBER() OVER(ORDER BY this_0_.Id) as __hibernate_sort_row FROM dbo.T1 this_0_) as query WHERE query.__hibernate_sort_row > @p2 ORDER BY query.__hibernate_sort_row)] ---> System.Data.SqlClient.SqlException: Must declare the scalar variable "@p1".
> Incorrect syntax near the keyword 'as'.
>    at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
>    ...
>    at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
>    at System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader()
>    at NHibernate.AdoNet.AbstractBatcher.ExecuteReader(IDbCommand cmd) in d:\CSharp\NH\NH\nhibernate\src\NHibernate\AdoNet\AbstractBatcher.cs:line 247
>    at NHibernate.Loader.Loader.GetResultSet(IDbCommand st, Boolean autoDiscoverTypes, Boolean callable, RowSelection selection, ISessionImplementor session) in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Loader\Loader.cs:line 1349
>    at NHibernate.Loader.Loader.DoQuery(ISessionImplementor session, QueryParameters queryParameters, Boolean returnProxies) in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Loader\Loader.cs:line 413
>    at NHibernate.Loader.Loader.DoQueryAndInitializeNonLazyCollections(ISessionImplementor session, QueryParameters queryParameters, Boolean returnProxies) in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Loader\Loader.cs:line 243
>    at NHibernate.Loader.Loader.DoList(ISessionImplementor session, QueryParameters queryParameters) in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Loader\Loader.cs:line 1694
>    --- End of inner exception stack trace ---
>    at NHibernate.Loader.Loader.DoList(ISessionImplementor session, QueryParameters queryParameters) in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Loader\Loader.cs:line 1703
>    at NHibernate.Loader.Loader.ListIgnoreQueryCache(ISessionImplementor session, QueryParameters queryParameters) in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Loader\Loader.cs:line 1601
>    at NHibernate.Loader.Loader.List(ISessionImplementor session, QueryParameters queryParameters, ISet`1 querySpaces, IType[] resultTypes) in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Loader\Loader.cs:line 1595
>    at NHibernate.Loader.Criteria.CriteriaLoader.List(ISessionImplementor session) in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Loader\Criteria\CriteriaLoader.cs:line 74
>    at NHibernate.Impl.SessionImpl.List(CriteriaImpl criteria, IList results) in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\SessionImpl.cs:line 1919
>    at NHibernate.Impl.CriteriaImpl.List(IList results) in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\CriteriaImpl.cs:line 265
>    at NHibernate.Impl.CriteriaImpl.List[T]() in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\CriteriaImpl.cs:line 276
>    at NHTest.Program.TestQuery() in D:\SVN\Podium\Source\NHTest\Program.cs:line 69
>    at NHTest.Program.Main(String[] args) in D:\SVN\Podium\Source\NHTest\Program.cs:line 26
> This is being run with .NET v4, though I don't believe that the framework version has an bearing.

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

        

[nhibernate-issues] [NHJIRA] Closed: (NH-2768) Programmaticaly switching lazy initialization off on certain properties

[Fabio M. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fabio Maulo closed NH-2768.
---------------------------

    Resolution: Not an Issue

from Invoice i join fetch i.InvoiceLines

> Programmaticaly switching lazy initialization off on certain properties       
> ------------------------------------------------------------------------------
>
>                 Key: NH-2768
>                 URL: http://216.121.112.228/browse/NH-2768
>             Project:  NHibernate
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Himanshu Kodwani
>
> Nhibernate supports lazy initialization. In some scenarios I prefer few properties to initialize lazily but other times I want those properties to be fetched along with the entity itself in a single select and join statement. This will give better performance when the user knows in advance what properties he'll be working on.
> Something like:
>  eg. ISession session.SwitchoffLazyOn("Invoice.InvoiceLines");
>  now when we'll fetch an invoice, invoice lines will be fetched along with it in a single sql join statement without the need for sending another sql statement to the db.
> If you already have such a feature then kindly let me know what section of the documentation covers it.

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

        

[nhibernate-issues] [NHJIRA] Resolved: (NH-2700) SqlFunctionProjection does not honor parameter order

[Fabio M. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fabio Maulo resolved NH-2700.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 3.2.0Beta2

Fixed with the whole refactoring of parameters management.

> SqlFunctionProjection does not honor parameter order
> ----------------------------------------------------
>
>                 Key: NH-2700
>                 URL: http://216.121.112.228/browse/NH-2700
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Andrei Alecu
>            Priority: Minor
>             Fix For: 3.2.0Beta2
>
>         Attachments: nh2700 failing test.patch
>
>
> If you define a function in a custom dialect that does not have the parameters in order and use SqlFunctionProjection, the generated sql is wrong, and does not honor parameter order.
> For example:
>      RegisterFunction(
>                     "AddDays",
>                     new SQLFunctionTemplate(
>                             NHibernateUtil.DateTime,
>                                 "dateadd(day,?2,?1)"
>  
>                             )
>                     );
>                 var proj = new SqlFunctionProjection("AddDays", NHibernateUtil.DateTime,
>                                                      new IProjection[]
>                                                          {
>                                                              Projections.Property<ModelClass>(p=>p.Date1),
>                                                              Projections.Property<ModelClass>(p=>p.Value1)
>                                                          });
> Generated SQL (buggy):
>     SELECT dateadd(day,this_.Date1,this_.Value1)
> Expected SQL:
>     SELECT dateadd(day,this_.Value1,this_.Date1)
> Using an HQL query honors parameter order properly
> I will attach a failing unit test.

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

        

[nhibernate-issues] [NHJIRA] Resolved: (NH-2125) Solution for NH2123 - Subselect in combination with a disjuction query causes an enormous memory cons

[Fabio M. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fabio Maulo resolved NH-2125.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 3.2.0Beta2

> Solution for NH2123 - Subselect in combination with a disjuction query causes an enormous memory cons
> -----------------------------------------------------------------------------------------------------
>
>                 Key: NH-2125
>                 URL: http://216.121.112.228/browse/NH-2125
>             Project:  NHibernate
>          Issue Type: Patch
>          Components: Core
>    Affects Versions: 2.1.2.GA
>            Reporter: martijn evens
>            Priority: Minor
>             Fix For: 3.2.0Beta2
>
>         Attachments: NH2123.patch
>
>
> Setup: 
> Simple Parent object linked to a simple Child object. The Child object is lazy loaded via subselect.
> When running a criteria query with a large disjunction (2000 params) on the parent object, which returns about 4000 objects, around 550Meg of memory is consumed. Just running the query causes this memory consumption, the child objects are not even touched or lazy loaded. I made a comparison with version 2.0.1 where only 40 Meg is consumed. 
> Fix:
> In Revision 3481, the method CreateSubselects in file Nhibernate\Loader\Loader.cs was changed.  Instead of using pre-created subselect statements a new subselect statement is created every time resulting in the described behavior.
> Moving back to using pre-created subselect statements, but leaving the rest of the code intact solved the issue.  

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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2214) Distinct and Row_number problem

[Julian M. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21305#action_21305 ] 

Julian Maughan commented on NH-2214:
------------------------------------

There is unfortunately a problem with the proposed solution that causes it to fail some of NHibernate's existing tests. For example, Criteria.CriteriaQueryTest.SubqueryPagination generates the following SQL where OVER ORDER BY is on a column that is not in the sub-query SELECT list.

SELECT TOP (1000) y0_ 
FROM ( 
	SELECT *, ROW_NUMBER() OVER(ORDER BY ???.studentId) as __hibernate_sort_row  
	FROM (
		SELECT this_0_.Name as y0_ 
		FROM Student this_0_ 
		WHERE this_0_.studentId > 1) as q_) as query 
WHERE query.__hibernate_sort_row > 1 
ORDER BY query.__hibernate_sort_row

Where the question marks are shown, there is no valid alias or table reference that will allow this statement to work. The column would have to be included in the inner-most sub-query's SELECT list, but this will cause DISTINCT queries to fail - which was the whole point of this patch.

> Distinct and Row_number problem
> -------------------------------
>
>                 Key: NH-2214
>                 URL: http://216.121.112.228/browse/NH-2214
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: DataProviders / Dialects
>    Affects Versions: 2.1.1.GA, 2.1.2.GA
>            Reporter: Carlos Martinez
>            Assignee: Julian Maughan
>            Priority: Major
>         Attachments: MsSql2005Dialect.cs, NH-2214-reproduction.zip, NH-2214.patch, NH-2214.patch, NH-2214.zip
>
>
> Microsoft.NET Framework 3.5
> MSSQL 2008
> Select distinct T.ID, T.Name from T
> inner join T2 on T.ID = T2.TID
> order by T.Name
> With this native query (using ISQLQuery) and the statement "DISTINCT" is necessary because the union wiht T2 produces duplicate results of T. 
> if I use
> SetFirstResult(index)
> SetMaxResults(max)
> It generates the following Query
> Select top max
>   ID,
>   Name  
>   from
>         (select distinct
>           ID,
>           Name,
>           ROW_NUMBER () over (order by T.Name) as __hibernate_sort_row
>           from T
>           inner join T2) as query
>     where __hibernate_sort_row > index
> first results are generated with ROW_NUMER, for example
> T.ID  T.Name   __hibernate_sort_row
> 2     Carlos   1
> 1     Juan     2
> 1     Juan     3
> 3     Paulina  4
> 4     Zunio    5
> 4     Zunio    6
> 4     Zunio    7
> Then "DISTINCT" no longer makes sense, because all records are different due to ROW_NUMBER.
> In version 2.0.1 GA works perfectly

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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2317) Select after Take does not work properly

[Fabio M. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21304#action_21304 ] 

Fabio Maulo commented on NH-2317:
---------------------------------

Yes are different cases:
artists.OrderBy(a => a.Age).Take(10).Select(a => a.Id)
artists.Take(10).OrderBy(a => a.Age).Select(a => a.Id)

Are two completely different SQL with different results.

> Select after Take does not work properly
> ----------------------------------------
>
>                 Key: NH-2317
>                 URL: http://216.121.112.228/browse/NH-2317
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.0.0.Alpha2
>            Reporter: Jose F. Romaniello
>            Priority: Major
>             Fix For: 3.2.0Beta2
>
>         Attachments: NH2317.7z
>
>
> artists.Take(10).Select(a => a.Id) throws exception on 
> NHibernate.Hql.Ast.ANTLR.PolymorphicQuerySourceDetector.GetClassName(IASTNode querySource) en PolymorphicQuerySourceDetector.cs: line 62
> artists.Select(a => a.Id).Take(10) works properly
> These two queries work with the old provider.

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

        

[nhibernate-issues] [NHJIRA] Resolved: (NH-2296) Subselect fetching strategy with a "SetMaxResults" query generates *extremely* inefficient sql

[Fabio M. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fabio Maulo resolved NH-2296.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 3.2.0Beta2

> Subselect fetching strategy with a "SetMaxResults" query generates *extremely* inefficient sql
> ----------------------------------------------------------------------------------------------
>
>                 Key: NH-2296
>                 URL: http://216.121.112.228/browse/NH-2296
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: DataProviders / Dialects
>    Affects Versions: 3.0.0.Alpha2
>            Reporter: Gabe Moothart
>            Priority: Critical
>             Fix For: 3.2.0Beta2
>
>         Attachments: NH2296.Test.patch, nhib_test.zip
>
>
> Observed in NHibernate 3.0 Alpha 2, and also 2.1.2.GA, with the SqlServer2008 dialect.
> Assume you have a master table with a one-to-many association on a detail table, and that association has the subselect fetching strategy.
> If you issue a simple query against the master object using SetMaxResults to restrict the number of rows returned, and then access one of the detail objects (triggering the subselect fetch query), the subselect sql will not be generated with a "TOP". This results in a query that returns an unbounded number of unnecessary records!
> A simple example, from the attached reproduction:
>     var qry = sess.CreateQuery("select o from Order o")
>                   .SetMaxResults(2)
>                   .List<Order>();
>     // trigger lazy-loading of products, using subselect fetch.
>     string sr = orders[0].Products[0].StatusReason;
> Generates the following sql:
>     NHibernate: select TOP (@p0) [...]
>     from [Order] order0_;@p0 = 2 [Type: Int32 (0)]
>      NHibernate: SELECT [...] FROM [Product] products0_ 
>      WHERE products0_.Order_id in (select order0_.Id from [Order] order0_)
> You can see that the subselect in the second query is unbounded and returns every Product attached to *any* order, not just the top two! I've attached a simple solution containing a reproducible test case. Run the console application and inspect the SQL that is output. You can clearly see what I am talking about.
> This makes subselect fetching practically useless for most scenarios. In my case it returns 20,000 rows when 20 or so would do. I consider it a critical issue.

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

        

[nhibernate-issues] [NHJIRA] Commented: (NHB-30) Release a 3.0.0 Alpha 1 build

[Brian C. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NHB-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21303#action_21303 ] 

Brian Chavez commented on NHB-30:
---------------------------------

We also need a NH 2.1.2 version as well.

> Release a 3.0.0 Alpha 1 build
> -----------------------------
>
>                 Key: NHB-30
>                 URL: http://216.121.112.228/browse/NHB-30
>             Project: NHibernate.Burrow
>          Issue Type: Task
>          Components:  Core
>    Affects Versions: 1.0.2 GA
>            Reporter: Jason Dentler
>            Assignee: Kailuo Wang
>            Priority: Minor
>
> Please release an official build for NH 3.0.0 Alpha 1 on SourceForge for inclusion in the NHForge Downloads. 
> Thanks,
> Jason

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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-1157) SubSelect Fetching does not work with MultiCriteria

[Fabio M. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21302#action_21302 ] 

Fabio Maulo commented on NH-1157:
---------------------------------

Can you provide the test ?
http://nhforge.org/blogs/nhibernate/archive/2008/10/04/the-best-way-to-solve-nhibernate-bugs-submit-good-unit-test.aspx

> SubSelect Fetching does not work with MultiCriteria
> ---------------------------------------------------
>
>                 Key: NH-1157
>                 URL: http://216.121.112.228/browse/NH-1157
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0.0.Alpha1
>            Reporter: Craig Neuwirt
>            Priority: Major
>
> I tried to create a unit test to demonstrate, but a lot of the unit tests seem to be failing.  Is this the case?
> Anyway, the Loader.Transpose is not properly handling the IList keys that are passed in.  The list
> show to be an array of arrays, but the method is treating it as a single Array.  I will continue to get a unit
> test in the mean time.

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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2521) Session.EnableFilter method should work for HQL-UPDATE statement

[Fabio M. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21301#action_21301 ] 

Fabio Maulo commented on NH-2521:
---------------------------------

Please attach a test case ASAP if you need it for NH3.2 (query-parameters management was completely re-wrote).
http://nhforge.org/blogs/nhibernate/archive/2008/10/04/the-best-way-to-solve-nhibernate-bugs-submit-good-unit-test.aspx

> Session.EnableFilter method should work for HQL-UPDATE statement
> ----------------------------------------------------------------
>
>                 Key: NH-2521
>                 URL: http://216.121.112.228/browse/NH-2521
>             Project:  NHibernate
>          Issue Type: Improvement
>          Components: DataProviders / Dialects
>    Affects Versions: 3.0.0.GA
>            Reporter: Hung Tran
>            Priority: Minor
>
> See the case below
> ?xml version="1.0" encoding="utf-8" ?>
> <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" auto-import="true" default-access="field.camelcase-underscore" default-lazy="true" default-cascade="none" >
>     <class name="Manufacturer" dynamic-update="true" dynamic-insert="true" optimistic-lock="version">
>         <id name="Id" unsaved-value="-1" type="Int64" length="18">
>             <generator class="native"/>
>         </id>
>         <version name="EntityVersion" unsaved-value="-1" type="Int32" />
>         <bag name="Categories" fetch="subselect" inverse="true" lazy="false" cascade="all-delete-orphan">
>             <key column="ManufacturerManufacturerCategory"/>
>             <one-to-many class="ManufacturerCategory"/>
>         </bag>
>         <property name="Code" type="String" length="255" unique-key="codeEntityCode"/>
>         <property name="Description" type="String" length="255"/>
>         <property name="Name" type="String" length="255"/>
>         <component name="RowInfo" class="RowInfo">
>             <property name="Status" type="NHibernate.Type.EnumStringType`1[[RowStatus, TestLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]], NHibernate, Version=3.0.1.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4" column="RowInfoStatus"/>
>         </component>
>         <filter name="rowFilter" condition="ROW_INFO_STATUS = :rowStatus"/>
>     </class>
>     <class name="ManufacturerCategory" dynamic-update="true" dynamic-insert="true">
>         <id name="Id" unsaved-value="-1" type="Int64" length="18">
>             <generator class="native"/>
>         </id>
>         <many-to-one name="Category" class="ProductCategory" column="Category" index="IX_FK_EA201C336482F24" lazy="proxy"/>
>         <many-to-one name="Manufacturer" class="Manufacturer" column="ManufacturerManufacturerCategory" index="IX_FK_EA201C33771511F1" lazy="proxy"/>
>     </class>
>     <class name="ProductCategory" dynamic-update="true" dynamic-insert="true" optimistic-lock="version">
>         <id name="Id" unsaved-value="-1" type="Int64" length="18">
>             <generator class="native"/>
>         </id>
>         <version name="EntityVersion" unsaved-value="-1" type="Int32" />
>         <property name="Code" type="String" length="255" unique-key="codeEntityCode"/>
>         <property name="Description" type="String" length="255"/>
>         <property name="Name" type="String" length="255"/>
>         <component name="RowInfo" class="RowInfo">
>             <property name="Status" type="NHibernate.Type.EnumStringType`1[[RowStatus, TestLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]], NHibernate, Version=3.0.1.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4" column="RowInfoStatus"/>
>         </component>
> 	<filter name="rowFilter" condition="ROW_INFO_STATUS = :rowStatus"/>
>     </class>
>     <class name="EzzySalon.SaleModule.Model.Item" dynamic-update="true" dynamic-insert="true" optimistic-lock="version" discriminator-value="Item">
>         <id name="Id" unsaved-value="-1" type="Int64" length="18">
>             <generator class="native"/>
>         </id>
>         <discriminator type="String">
>             <column name="EntityDiscriminator" not-null="1" length="50" index="IX_TYPE_742DC178E1FAC3A0"/>
>         </discriminator>
>         <version name="EntityVersion" unsaved-value="-1" type="Int32" />
>         <property name="Barcode" type="String" length="20" index="IX_CODE_742DC17839B4419A" unique-key="barcode"/>
>         <property name="Description" type="String" length="200"/>
>         <property name="Discountable" type="Boolean"/>
>         <property name="Name" type="String" length="100" unique-key="itemName"/>
>         <component name="Price1" class="ItemPrice">
>             <property name="ExcVat" type="Decimal" column="Price1ExcVat"/>
>             <property name="ExcVatCreep" type="Decimal" column="Price1ExcVatCreep"/>
>             <property name="IncVat" type="Decimal" column="Price1IncVat"/>
>             <property name="IncVatCreep" type="Decimal" column="Price1IncVatCreep"/>
>         </component>
>         <component name="RowInfo" class="RowInfo">
>             <property name="Status" type="NHibernate.Type.EnumStringType`1[[RowStatus, TestLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]], NHibernate, Version=3.0.1.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4" column="RowInfoStatus"/>
>         </component>
>         <subclass name="StockItem" discriminator-value="StockItem" dynamic-update="true" dynamic-insert="true">
>             <property name="DefaultOrderCode" type="String" length="20"/>
>             <property name="IsProfessional" type="Boolean"/>
>             <property name="NumberRequired" type="Int32"/>
>             <property name="PackageSize" type="Int32"/>
>             <property name="PackageUnit" type="String" length="20"/>
>             <property name="Quantity" type="Int32"/>
>             <many-to-one name="Range" class="ManufacturerCategory" column="Range" index="IX_FK_4CAB57F44871503B" lazy="proxy"/>
>             <property name="Size" type="String" length="20"/>
>             <property name="StockLow" type="Int32"/>
>             <property name="StockOnOrder" type="Int32"/>
>         </subclass>
> 	<filter name="rowFilter" condition="ROW_INFO_STATUS = :rowStatus"/>
>     </class>
>     <filter-def name="rowFilter">
>         <filter-param name="rowStatus" type="NHibernate.Type.EnumStringType`1[[RowStatus, TestLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]], NHibernate, Version=3.0.1.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4"/>
>     </filter-def>
> </hibernate-mapping>
> HQL: UPDATE StockItem s
>         SET s.Price1.ExcVatCreep = s.Price1.ExcVat * (1 + :perPrice1) + :moneyPrice1
>      WHERE s.Range in (SELECT mc.Id 
>                        FROM ManufacturerCategory mc 
>                                left join mc.Manufacturer m
>                                left join mc.Category p
> 		       WHERE m.Code = :mCode and p.Code = :pCode)
> I got an exception below when the 'rowFilter' filter is enabled
> NHibernate.Exceptions.GenericADOException : could not execute update query[SQL: 
> update `UT_ITEM` 
>   set `PRICE1_EXC_VAT_CREEP`=`PRICE1_EXC_VAT`*(1+?)+? 
> where `ENTITY_DISCRIMINATOR`='StockItem' 
>   and (`RANGE` in (select manufactur1_.`ID` 
>                    from `UT_MANUFACTURER_CATEGORY` manufactur1_ 
>                               left outer join `UT_MANUFACTURER` manufactur2_ 
>                                  on manufactur1_.`MANUFACTURER_MANUFACTURER_CATEGORY`=manufactur2_.`ID` 
>                                  and manufactur2_.ROW_INFO_STATUS = :rowFilter.rowStatus 
>                               left outer join `UT_PRODUCT_CATEGORY` productcat3_ 
>                                  on manufactur1_.`CATEGORY`=productcat3_.`ID` 
>                                  and productcat3_.ROW_INFO_STATUS = :rowFilter.rowStatus 
>                    where manufactur2_.`CODE`=? and productcat3_.`CODE`=?))]
> ----> MySql.Data.MySqlClient.MySqlException : You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'manufactur2_.ROW_INFO_STATUS = :rowFilter.rowStatus lef' at line 1
> There are two serious problems here
> 1) In HQL, I am using name parameter, but in generated SQL, it's position parameter (I am using NHibernate.Driver.MySqlDataDriver, NHibernate.Dialect.MySQL5Dialect which supports name parameter) 
> 2) The rowFilter is not applied for UPDATE

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