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

[nhibernate-issues] [NHJIRA] Commented: (NH-2661) NHibernate cannot handle SQL Server TIME columns when built with the .NET 4 framework

[Neal G. (JIRA) <nh...@gm...>]

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

Neal Groothuis commented on NH-2661:
------------------------------------

The exact code that I added to NHibernate.Driver.SqlClientDriver is:

        protected override void InitializeParameter(IDbDataParameter
dbParam, string name, SqlType sqlType)
        {
            base.InitializeParameter(dbParam, name, sqlType);
            if (sqlType.DbType == DbType.Time)
                ((SqlParameter) dbParam).SqlDbType = SqlDbType.Time;
        } 

I verified that the unit test passes after I made this change (and updated the type of the "Data" property to reference my included custom TimeType).

> NHibernate cannot handle SQL Server TIME columns when built with the .NET 4 framework
> -------------------------------------------------------------------------------------
>
>                 Key: NH-2661
>                 URL: http://216.121.112.228/browse/NH-2661
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Neal Groothuis
>            Priority: Minor
>         Attachments: NHibernate.Test-2661.zip
>
>
> In .NET 4, setting a SqlParameter's DbType to Time does not work; it will be set to DateTime instead.  (http://msdn.microsoft.com/en-us/library/system.data.dbtype%28v=VS.100%29.aspx , c.f. http://msdn.microsoft.com/en-us/library/system.data.dbtype%28v=VS.90%29.aspx ).  To set a SqlParameter's DbType to Time, you actually have to set the SqlDbType property to SqlDbType.Time.  
> Unfortunately, this renders NHibernate unable to access TIME columns in the database if being used in .NET 4.0.  

-- 
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-1940) NHibernate.Bytecode inconsistently named

[Kenneth S. M. (J. <nh...@gm...>]

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

Kenneth Siewers Møller commented on NH-1940:
--------------------------------------------

Beautiful! But shouldn't the resolution then be "Fixed" and fix version "3.2.0 GA"? Just a suggestion... :)

> NHibernate.Bytecode inconsistently named
> ----------------------------------------
>
>                 Key: NH-1940
>                 URL: http://216.121.112.228/browse/NH-1940
>             Project:  NHibernate
>          Issue Type: Improvement
>          Components: ByteCode providers, Core
>    Affects Versions: 2.1.0.GA
>            Reporter: Nick Aceves
>
> The NHibernate.Bytecode namespace is not named consistently between NHibernate.dll and NHibernate.ByteCode.Castle.dll.
> NHibernate.dll calls it "NHibernate.Bytecode".
> NHibernate.ByteCode.Castle.dll calls it "NHibernate.ByteCode".
> The only difference between them is the capitalization of the "c" in "Bytecode".
> This has some interesting interplay with what seems to be a bug in ReSharper. ReSharper will only show NHibernate.Bytecode in intellisense, even when NHibernate.ByteCode.Castle.dll is referenced, which led to me spending about 15 minutes figuring out why I couldn't find the Castle ProxyFactoryFactory class.

-- 
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-2662) Casting a joined alias in QueryOver loses alias context and looks for property on QueryOver root

[Graeme F. (JIRA) <nh...@gm...>]

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

Graeme Foster updated NH-2662:
------------------------------

    Attachment: NH2662.zip

Zip file in standard NH test format to illustrate problem.

> Casting a joined alias in QueryOver loses alias context and looks for property on QueryOver root
> ------------------------------------------------------------------------------------------------
>
>                 Key: NH-2662
>                 URL: http://216.121.112.228/browse/NH-2662
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: QueryOver
>    Affects Versions: 3.2.0Alpha2
>            Reporter: Graeme Foster
>            Priority: Major
>         Attachments: NH2662.zip
>
>
> If you QueryOver an entity, alias-join to a property on that entity which has an inheritance tree, and then attempt to project a property on a specific subclass of the entity, the property path loses the context of the alias and attempts to find it on the queryover root.
> Pseudo code:
> QueryOver<Customer>()
> .JoinAlias(c => c.Order, () => orderAlias)
> .SelectList(list => list.Select( () => ((SpecialOrder)orderAlias).SpecialReason);
> blows up.
> The equivalent in linq-nhibernate works OK which is why I think this is a bug.
> Query<Customer>().Select( c => new { SpecialReason = ((SpecialOrder)c.Order).SpecialReason } );
> Will attach issue zip in same format as NH Trunk issues.
> Graeme

-- 
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-2662) Casting a joined alias in QueryOver loses alias context and looks for property on QueryOver root

[Graeme F. (JIRA) <nh...@gm...>]

Casting a joined alias in QueryOver loses alias context and looks for property on QueryOver root
------------------------------------------------------------------------------------------------

                 Key: NH-2662
                 URL: http://216.121.112.228/browse/NH-2662
             Project:  NHibernate
          Issue Type: Bug
          Components: QueryOver
    Affects Versions: 3.2.0Alpha2
            Reporter: Graeme Foster
            Priority: Major


If you QueryOver an entity, alias-join to a property on that entity which has an inheritance tree, and then attempt to project a property on a specific subclass of the entity, the property path loses the context of the alias and attempts to find it on the queryover root.

Pseudo code:

QueryOver<Customer>()
.JoinAlias(c => c.Order, () => orderAlias)
.SelectList(list => list.Select( () => ((SpecialOrder)orderAlias).SpecialReason);

blows up.

The equivalent in linq-nhibernate works OK which is why I think this is a bug.
Query<Customer>().Select( c => new { SpecialReason = ((SpecialOrder)c.Order).SpecialReason } );

Will attach issue zip in same format as NH Trunk issues.

Graeme


-- 
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-2658) Linq provider overcaching HQL

[Daniel G. (JIRA) <nh...@gm...>]

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

Daniel Guenter commented on NH-2658:
------------------------------------

I have a patch (HG) which solves this issue.

https://bitbucket.org/nicaog/nhibernate-patches/changeset/8ea3eb358e61

However it does introduce a new concept into the system. IHqlGenerator(s) are allowed to participate in the initial building of the expression tree and key through the use of a SpecialMemberVisitor and a new interface method called Visit.  This allows for expression replacing and parameter manipulation before the expression key is finalized. 

This solution may be a bit more intrusive than I had hoped it would be. However it does allow for more advanced and intelligent hql generators.

> Linq provider overcaching HQL
> -----------------------------
>
>                 Key: NH-2658
>                 URL: http://216.121.112.228/browse/NH-2658
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.1.0
>            Reporter: Daniel Guenter
>            Priority: Major
>         Attachments: NH2658_failing_test_case.patch
>
>
> The linq provider caches a query assuming that ALL constants will be turned into HQL parameters. Sometimes this is not the case. A linq extension that selects a concrete entity property based on a constant value will never pass that value into HQL.
> This is also a blocking issue in getting Linq to work with dynamic-components.  The string value passed into the dictionary (dict["key"] == x) cannot be passed to HQL as a parameter as it is directly evaluating a property name. Thus the first query will work but subsequent queries will be wrong and will reuse the column/property name of the first cached query. 

-- 
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-2661) NHibernate cannot handle SQL Server TIME columns when built with the .NET 4 framework

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

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

Fabio Maulo closed NH-2661.
---------------------------

    Resolution: External Issue

http://connect.microsoft.com/VisualStudio/feedback/details/381934/sqlparameter-dbtype-dbtype-time-sets-the-parameter-to-sqldbtype-datetime-instead-of-sqldbtype-time
Microsoft said:
"Thanks for reporting this issue. This is a bug in our product, but after carefully investigating the issue, we have decided not to fix the bug. Fixing this bug will cause a breaking change and in most of customer scenarios, they should be able to use SqlParameter.SqlDbType. Please let us know if this is a blocking issue for some of your major scenarios."

> NHibernate cannot handle SQL Server TIME columns when built with the .NET 4 framework
> -------------------------------------------------------------------------------------
>
>                 Key: NH-2661
>                 URL: http://216.121.112.228/browse/NH-2661
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Neal Groothuis
>            Priority: Minor
>         Attachments: NHibernate.Test-2661.zip
>
>
> In .NET 4, setting a SqlParameter's DbType to Time does not work; it will be set to DateTime instead.  (http://msdn.microsoft.com/en-us/library/system.data.dbtype%28v=VS.100%29.aspx , c.f. http://msdn.microsoft.com/en-us/library/system.data.dbtype%28v=VS.90%29.aspx ).  To set a SqlParameter's DbType to Time, you actually have to set the SqlDbType property to SqlDbType.Time.  
> Unfortunately, this renders NHibernate unable to access TIME columns in the database if being used in .NET 4.0.  

-- 
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-2661) NHibernate cannot handle SQL Server TIME columns when built with the .NET 4 framework

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

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

Fabio Maulo updated NH-2661:
----------------------------

    Affects Version/s:     (was: 3.0.0.GA)
                           (was: 3.0.0.CR1)
                           (was: 3.0.0.Beta2)
                           (was: 3.0.0.Beta1)
                           (was: 3.0.0.Alpha3)
                           (was: 3.0.0.Alpha2)
                           (was: 2.1.2.GA)
                           (was: 2.1.1.GA)
                           (was: 3.0.0.Alpha1)

> NHibernate cannot handle SQL Server TIME columns when built with the .NET 4 framework
> -------------------------------------------------------------------------------------
>
>                 Key: NH-2661
>                 URL: http://216.121.112.228/browse/NH-2661
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Neal Groothuis
>            Priority: Minor
>         Attachments: NHibernate.Test-2661.zip
>
>
> In .NET 4, setting a SqlParameter's DbType to Time does not work; it will be set to DateTime instead.  (http://msdn.microsoft.com/en-us/library/system.data.dbtype%28v=VS.100%29.aspx , c.f. http://msdn.microsoft.com/en-us/library/system.data.dbtype%28v=VS.90%29.aspx ).  To set a SqlParameter's DbType to Time, you actually have to set the SqlDbType property to SqlDbType.Time.  
> Unfortunately, this renders NHibernate unable to access TIME columns in the database if being used in .NET 4.0.  

-- 
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-2661) NHibernate cannot handle SQL Server TIME columns when built with the .NET 4 framework

[Neal G. (JIRA) <nh...@gm...>]

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

Neal Groothuis commented on NH-2661:
------------------------------------

I believe this can be fixed by having NHibernate.Driver.SqlClientDriver override InitializeParameter() and set the SqlDbType to Time if the DbType is Time.

> NHibernate cannot handle SQL Server TIME columns when built with the .NET 4 framework
> -------------------------------------------------------------------------------------
>
>                 Key: NH-2661
>                 URL: http://216.121.112.228/browse/NH-2661
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.1.1.GA, 2.1.2.GA, 3.0.0.Alpha1, 3.0.0.Alpha2, 3.0.0.Alpha3, 3.0.0.Beta1, 3.0.0.Beta2, 3.0.0.CR1, 3.0.0.GA, 3.1.0
>            Reporter: Neal Groothuis
>            Priority: Minor
>         Attachments: NHibernate.Test-2661.zip
>
>
> In .NET 4, setting a SqlParameter's DbType to Time does not work; it will be set to DateTime instead.  (http://msdn.microsoft.com/en-us/library/system.data.dbtype%28v=VS.100%29.aspx , c.f. http://msdn.microsoft.com/en-us/library/system.data.dbtype%28v=VS.90%29.aspx ).  To set a SqlParameter's DbType to Time, you actually have to set the SqlDbType property to SqlDbType.Time.  
> Unfortunately, this renders NHibernate unable to access TIME columns in the database if being used in .NET 4.0.  

-- 
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-2661) NHibernate cannot handle SQL Server TIME columns when built with the .NET 4 framework

[Neal G. (JIRA) <nh...@gm...>]

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

Neal Groothuis updated NH-2661:
-------------------------------

    Attachment: NHibernate.Test-2661.zip

Unit test illustrating the problem.  This includes a custom TimeType which works around the problem in NH-2660.

> NHibernate cannot handle SQL Server TIME columns when built with the .NET 4 framework
> -------------------------------------------------------------------------------------
>
>                 Key: NH-2661
>                 URL: http://216.121.112.228/browse/NH-2661
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.1.1.GA, 2.1.2.GA, 3.0.0.Alpha1, 3.0.0.Alpha2, 3.0.0.Alpha3, 3.0.0.Beta1, 3.0.0.Beta2, 3.0.0.CR1, 3.0.0.GA, 3.1.0
>            Reporter: Neal Groothuis
>            Priority: Minor
>         Attachments: NHibernate.Test-2661.zip
>
>
> In .NET 4, setting a SqlParameter's DbType to Time does not work; it will be set to DateTime instead.  (http://msdn.microsoft.com/en-us/library/system.data.dbtype%28v=VS.100%29.aspx , c.f. http://msdn.microsoft.com/en-us/library/system.data.dbtype%28v=VS.90%29.aspx ).  To set a SqlParameter's DbType to Time, you actually have to set the SqlDbType property to SqlDbType.Time.  
> Unfortunately, this renders NHibernate unable to access TIME columns in the database if being used in .NET 4.0.  

-- 
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-2661) NHibernate cannot handle SQL Server TIME columns when built with the .NET 4 framework

[Neal G. (JIRA) <nh...@gm...>]

NHibernate cannot handle SQL Server TIME columns when built with the .NET 4 framework
-------------------------------------------------------------------------------------

                 Key: NH-2661
                 URL: http://216.121.112.228/browse/NH-2661
             Project:  NHibernate
          Issue Type: Bug
          Components: Core
    Affects Versions: 3.1.0, 3.0.0.GA, 3.0.0.CR1, 3.0.0.Beta2, 3.0.0.Beta1, 3.0.0.Alpha3, 3.0.0.Alpha2, 3.0.0.Alpha1, 2.1.2.GA, 2.1.1.GA
            Reporter: Neal Groothuis
            Priority: Minor


In .NET 4, setting a SqlParameter's DbType to Time does not work; it will be set to DateTime instead.  (http://msdn.microsoft.com/en-us/library/system.data.dbtype%28v=VS.100%29.aspx , c.f. http://msdn.microsoft.com/en-us/library/system.data.dbtype%28v=VS.90%29.aspx ).  To set a SqlParameter's DbType to Time, you actually have to set the SqlDbType property to SqlDbType.Time.  

Unfortunately, this renders NHibernate unable to access TIME columns in the database if being used in .NET 4.0.  

-- 
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-2660) Db.Time types are being set as DateTime

[Neal G. (JIRA) <nh...@gm...>]

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

Neal Groothuis updated NH-2660:
-------------------------------

    Attachment: NHibernate.Test.zip

Test case illustrating the problem.

> Db.Time types are being set as DateTime
> ---------------------------------------
>
>                 Key: NH-2660
>                 URL: http://216.121.112.228/browse/NH-2660
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Neal Groothuis
>            Priority: Minor
>         Attachments: NHibernate.Test.zip
>
>
> NHibernate.Type.TimeAsTimeSpanType and NHibernate.Type.TimeType add DateTime parameters to the commands passed to their Set() methods, but per this MSDN article: http://msdn.microsoft.com/en-us/library/cc716729.aspx , the .NET datatype that should be used for DbType.Time fields is TimeSpan.  At least when trying to update TIME columns with SQL Server 2008, this causes an error.  
> I believe that this can be fairly easily corrected by having the Set() methods save TimeSpans rather than DateTimes to the parameter list.

-- 
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-2660) Db.Time types are being set as DateTime

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

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

Fabio Maulo updated NH-2660:
----------------------------

    Affects Version/s:     (was: 3.0.0.GA)
                           (was: 3.0.0.CR1)
                           (was: 3.0.0.Beta2)
                           (was: 3.0.0.Beta1)
                           (was: 3.0.0.Alpha3)
                           (was: 3.0.0.Alpha2)
                           (was: 2.1.2.GA)
                           (was: 2.1.1.GA)
                           (was: 3.0.0.Alpha1)

> Db.Time types are being set as DateTime
> ---------------------------------------
>
>                 Key: NH-2660
>                 URL: http://216.121.112.228/browse/NH-2660
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Neal Groothuis
>            Priority: Minor
>
> NHibernate.Type.TimeAsTimeSpanType and NHibernate.Type.TimeType add DateTime parameters to the commands passed to their Set() methods, but per this MSDN article: http://msdn.microsoft.com/en-us/library/cc716729.aspx , the .NET datatype that should be used for DbType.Time fields is TimeSpan.  At least when trying to update TIME columns with SQL Server 2008, this causes an error.  
> I believe that this can be fairly easily corrected by having the Set() methods save TimeSpans rather than DateTimes to the parameter list.

-- 
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-2660) Db.Time types are being set as DateTime

[Neal G. (JIRA) <nh...@gm...>]

Db.Time types are being set as DateTime
---------------------------------------

                 Key: NH-2660
                 URL: http://216.121.112.228/browse/NH-2660
             Project:  NHibernate
          Issue Type: Bug
          Components: Core
    Affects Versions: 3.1.0, 3.0.0.GA, 3.0.0.CR1, 3.0.0.Beta2, 3.0.0.Beta1, 3.0.0.Alpha3, 3.0.0.Alpha2, 3.0.0.Alpha1, 2.1.2.GA, 2.1.1.GA
            Reporter: Neal Groothuis
            Priority: Minor


NHibernate.Type.TimeAsTimeSpanType and NHibernate.Type.TimeType add DateTime parameters to the commands passed to their Set() methods, but per this MSDN article: http://msdn.microsoft.com/en-us/library/cc716729.aspx , the .NET datatype that should be used for DbType.Time fields is TimeSpan.  At least when trying to update TIME columns with SQL Server 2008, this causes an error.  

I believe that this can be fairly easily corrected by having the Set() methods save TimeSpans rather than DateTimes to the parameter list.

-- 
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-2658) Linq provider overcaching HQL

[Daniel G. (JIRA) <nh...@gm...>]

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

Daniel Guenter updated NH-2658:
-------------------------------

    Attachment: NH2658_failing_test_case.patch

You will have to import the files into the project.

> Linq provider overcaching HQL
> -----------------------------
>
>                 Key: NH-2658
>                 URL: http://216.121.112.228/browse/NH-2658
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.1.0
>            Reporter: Daniel Guenter
>            Priority: Major
>         Attachments: NH2658_failing_test_case.patch
>
>
> The linq provider caches a query assuming that ALL constants will be turned into HQL parameters. Sometimes this is not the case. A linq extension that selects a concrete entity property based on a constant value will never pass that value into HQL.
> This is also a blocking issue in getting Linq to work with dynamic-components.  The string value passed into the dictionary (dict["key"] == x) cannot be passed to HQL as a parameter as it is directly evaluating a property name. Thus the first query will work but subsequent queries will be wrong and will reuse the column/property name of the first cached query. 

-- 
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-2659) Wrong string concatentation when using MS-SQL CE

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

Wrong string concatentation when using MS-SQL CE
------------------------------------------------

                 Key: NH-2659
                 URL: http://216.121.112.228/browse/NH-2659
             Project:  NHibernate
          Issue Type: Bug
          Components: DataProviders / Dialects
    Affects Versions: 3.1.0, 3.0.0.GA
            Reporter: Christian
            Priority: Major


There is already an issue in NHibernate.Linq, but actually this has nothing to do with LINQ.
See NHLQ-90.

-- 
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-2658) Linq provider overcaching HQL

[Daniel G. (JIRA) <nh...@gm...>]

Linq provider overcaching HQL
-----------------------------

                 Key: NH-2658
                 URL: http://216.121.112.228/browse/NH-2658
             Project:  NHibernate
          Issue Type: Bug
          Components: Linq Provider
    Affects Versions: 3.1.0
            Reporter: Daniel Guenter
            Priority: Major


The linq provider caches a query assuming that ALL constants will be turned into HQL parameters. Sometimes this is not the case. A linq extension that selects a concrete entity property based on a constant value will never pass that value into HQL.

This is also a blocking issue in getting Linq to work with dynamic-components.  The string value passed into the dictionary (dict["key"] == x) cannot be passed to HQL as a parameter as it is directly evaluating a property name. Thus the first query will work but subsequent queries will be wrong and will reuse the column/property name of the first cached query. 

-- 
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-1940) NHibernate.Bytecode inconsistently named

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

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

Fabio Maulo commented on NH-1940:
---------------------------------

Kenneth. In NH3.2.0 was fixed.


> NHibernate.Bytecode inconsistently named
> ----------------------------------------
>
>                 Key: NH-1940
>                 URL: http://216.121.112.228/browse/NH-1940
>             Project:  NHibernate
>          Issue Type: Improvement
>          Components: ByteCode providers, Core
>    Affects Versions: 2.1.0.GA
>            Reporter: Nick Aceves
>
> The NHibernate.Bytecode namespace is not named consistently between NHibernate.dll and NHibernate.ByteCode.Castle.dll.
> NHibernate.dll calls it "NHibernate.Bytecode".
> NHibernate.ByteCode.Castle.dll calls it "NHibernate.ByteCode".
> The only difference between them is the capitalization of the "c" in "Bytecode".
> This has some interesting interplay with what seems to be a bug in ReSharper. ReSharper will only show NHibernate.Bytecode in intellisense, even when NHibernate.ByteCode.Castle.dll is referenced, which led to me spending about 15 minutes figuring out why I couldn't find the Castle ProxyFactoryFactory class.

-- 
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-1940) NHibernate.Bytecode inconsistently named

[Kenneth S. M. (J. <nh...@gm...>]

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

Kenneth Siewers Møller commented on NH-1940:
--------------------------------------------

I just noticed this. It's a scratch in an otherwise polished surface :(

> NHibernate.Bytecode inconsistently named
> ----------------------------------------
>
>                 Key: NH-1940
>                 URL: http://216.121.112.228/browse/NH-1940
>             Project:  NHibernate
>          Issue Type: Improvement
>          Components: ByteCode providers, Core
>    Affects Versions: 2.1.0.GA
>            Reporter: Nick Aceves
>
> The NHibernate.Bytecode namespace is not named consistently between NHibernate.dll and NHibernate.ByteCode.Castle.dll.
> NHibernate.dll calls it "NHibernate.Bytecode".
> NHibernate.ByteCode.Castle.dll calls it "NHibernate.ByteCode".
> The only difference between them is the capitalization of the "c" in "Bytecode".
> This has some interesting interplay with what seems to be a bug in ReSharper. ReSharper will only show NHibernate.Bytecode in intellisense, even when NHibernate.ByteCode.Castle.dll is referenced, which led to me spending about 15 minutes figuring out why I couldn't find the Castle ProxyFactoryFactory class.

-- 
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-2405) MySQL5InnoDBDialect

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

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

Brendan updated NH-2405:
------------------------

    Attachment: MySQL5InnoDBDialect.cs

The only change required for this to work is to port:
https://github.com/hibernate/hibernate-core/blob/master/hibernate-core/src/main/java/org/hibernate/dialect/MySQL5InnoDBDialect.java

Please find this attached.

> MySQL5InnoDBDialect
> -------------------
>
>                 Key: NH-2405
>                 URL: http://216.121.112.228/browse/NH-2405
>             Project:  NHibernate
>          Issue Type: New Feature
>          Components: DataProviders / Dialects
>    Affects Versions: 2.1.2.GA
>            Reporter: Hung Tran
>         Attachments: MySQL5InnoDBDialect.cs
>
>
> I have tried to use MySQL5Dialect, but i got no luck, it did not help me generate DDL to create InnoDB table. I have looking for a dialect like MySQL5InnoDBDialect in Hibernate.  

-- 
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-2647) Forward mapping and db types

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

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

Fabio Maulo closed NH-2647.
---------------------------

    Resolution: Not an Issue

> Forward mapping and db types
> ----------------------------
>
>                 Key: NH-2647
>                 URL: http://216.121.112.228/browse/NH-2647
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.0.0.GA
>            Reporter: David Popiashvili
>            Priority: Minor
>         Attachments: NHibernateTest.rar
>
>
> When we create database from our *.hbm mapping files, some of the data types are not mapped correctly to the db. For example, NHibernate ignores Precision and Scale properties for decimal type. Also there's strange behavior with AnsiString, for example this property
> <property name="Username" length="15" type="AnsiString" /> is mapped as nvarchar(1) on the database, shouldn't it be varchar(15)?
> We are using .NET 4, NHibernate 3.0 and SQL Server 2008

-- 
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-2647) Forward mapping and db types

[David P. (JIRA) <nh...@gm...>]

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

David Popiashvili commented on NH-2647:
---------------------------------------

Fabio, I had the problem because I didn't pay attention that I was using MsSqlCeDialect with SQL Server 2008. I changed the dialect to MsSql2008Dialect and the problem is gone. So this is not your bug guys, just my stupid error. Please close this issue. 
Thanks and sorry for false alarm :)

> Forward mapping and db types
> ----------------------------
>
>                 Key: NH-2647
>                 URL: http://216.121.112.228/browse/NH-2647
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.0.0.GA
>            Reporter: David Popiashvili
>            Priority: Minor
>         Attachments: NHibernateTest.rar
>
>
> When we create database from our *.hbm mapping files, some of the data types are not mapped correctly to the db. For example, NHibernate ignores Precision and Scale properties for decimal type. Also there's strange behavior with AnsiString, for example this property
> <property name="Username" length="15" type="AnsiString" /> is mapped as nvarchar(1) on the database, shouldn't it be varchar(15)?
> We are using .NET 4, NHibernate 3.0 and SQL Server 2008

-- 
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-2618) FireBird GUID Type coversion error

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

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

Fabio Maulo closed NH-2618.
---------------------------

    Resolution: Not an Issue

> FireBird GUID Type coversion error
> ----------------------------------
>
>                 Key: NH-2618
>                 URL: http://216.121.112.228/browse/NH-2618
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: DataProviders / Dialects
>    Affects Versions: 3.0.0.GA
>            Reporter: Eugenyi Vinogradnyi
>            Priority: Major
>
> Firebird 2.5 store Uuid into left to right convetion as "CHAR(16) CHARACTER SET OCTETS" (see http://www.firebirdfaq.org/faq98/). But NHibernate into GuidType constructs System.Guid with System.Guid(byte[]) constructor, but System.GuidType shoul be constructed with Guid(int a, short b, short c, byte d, byte e, byte f, byte g, byte h, byte i, byte j, byte k) for correct representation. Also see Firebird 2.5 embeded fuctions UUID_TO_CHAR() and CHAR_TO_UUID().
> System.Guid reflection:
> {{{
>         // Creates a new guid from an array of bytes.
>         // 
>         public Guid(byte[] b)
>         {
>             if (b==null)
>                 throw new ArgumentNullException("b"); 
>             if (b.Length != 16)
>                 throw new ArgumentException(String.Format(CultureInfo.CurrentCulture, Environment.GetResourceString("Arg_GuidArrayCtor"), "16")); 
>  
>             _a = ((int)b[3] << 24) | ((int)b[2] << 16) | ((int)b[1] << 8) | b[0];
>             _b = (short)(((int)b[5] << 8) | b[4]); 
>             _c = (short)(((int)b[7] << 8) | b[6]);
>             _d = b[8];
>             _e = b[9];
>             _f = b[10]; 
>             _g = b[11];
>             _h = b[12]; 
>             _i = b[13]; 
>             _j = b[14];
>             _k = b[15]; 
>         }
>         // Creates a new GUID initialized to the value represented by the 
>         // arguments.  The bytes are specified like this to avoid endianness issues. 
>         //
>         public Guid(int a, short b, short c, byte d, byte e, byte f, byte g, byte h, byte i, byte j, byte k) 
>         {
>             _a = a;
>             _b = b;
>             _c = c; 
>             _d = d;
>             _e = e; 
>             _f = f; 
>             _g = g;
>             _h = h; 
>             _i = i;
>             _j = j;
>             _k = k;
>         } 
> }}}
> Database SQL script example:
> {{{
> CREATE DOMAIN FGUID_D_KEY AS CHAR(16) CHARACTER SET OCTETS NOT NULL;
> CREATE DOMAIN FGUID_D AS CHAR(16) CHARACTER SET OCTETS; 
> CREATE TABLE SYSTEM$DATABASE (
>   SYSTEM_GUID     FGUID_D_KEY,
>   SUBSYSTEM_GUID  FGUID_D_KEY
> );
> SET TERM ^ ;
> CREATE OR ALTER TRIGGER SYSTEM$DATABASE_BI0 FOR SYSTEM$DATABASE
> ACTIVE BEFORE INSERT POSITION 0
> AS
> BEGIN
>   /* Gen SYSTEM_GUID if not defined */
>   IF (NEW.SYSTEM_GUID IS NULL) THEN
>   BEGIN
>     NEW.SYSTEM_GUID = GEN_UUID();
>   END
>   /* Gen SUBSYSTEM_GUID if not defined */
>   IF (NEW.SUBSYSTEM_GUID IS NULL) THEN
>   BEGIN
>     NEW.SUBSYSTEM_GUID = GEN_UUID();
>   END
> END
> ^
> SET TERM ; ^
> INSERT INTO SYSTEM$DATABASE (SYSTEM_GUID, SUBSYSTEM_GUID) VALUES (NULL, NULL);
> }}}
> Symbolic example of NUnit test:
> {{{
>     ...
>     private class Guids
>     {
>       public Guid MsGuid { get; set; }
>       public string FbStrGuid { get; set; }
>     }
>     [Test]
>     public void TestFunc()
>     {
>       tempDbWrapper.WrapSession(
>         session =>
>           {
>             var guids =
>               session.CreateSQLQuery(
>                 "SELECT SYSTEM_GUID, UUID_TO_CHAR(SYSTEM_GUID) AS SYSTEM_GUID2  FROM SYSTEM$DATABASE")
>                 .SetResultTransformer(
>                   new FuzzyAliasToBeanResultTransformer<Guids>()
>                     .AddBeanProp("SYSTEM_GUID", "MsGuid")
>                     .AddBeanProp("SYSTEM_GUID2", "FbStrGuid"))
>                 .UniqueResult<Guids>();
>             var fbGuid = new Guid(guids.FbStrGuid);
>             Console.WriteLine("MSGuid = {0}", guids.MsGuid);
>             Console.WriteLine("DBGuid = {0}", fbGuid);
>             Assert.AreEqual(guids.MsGuid, fbGuid);
>           });
>     }
> }}}
> Execution Result:
> {{{
> TestFunc : Failed
> NHibernate: SELECT SYSTEM_GUID, UUID_TO_CHAR(SYSTEM_GUID) AS SYSTEM_GUID2  FROM SYSTEM$DATABASE
> MSGuid = cbe4709d-5cea-4078-b1f5-2adabdcdb1f7
> DBGuid = 9d70e4cb-ea5c-7840-b1f5-2adabdcdb1f7
>   Expected: cbe4709d-5cea-4078-b1f5-2adabdcdb1f7
>   But was:  9d70e4cb-ea5c-7840-b1f5-2adabdcdb1f7
> }}}
>  
> Best regards,
> Eugenyi Vinogradnyi (aka ssdi).

-- 
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-2647) Forward mapping and db types

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

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

Fabio Maulo commented on NH-2647:
---------------------------------

David,
For which dialect you are experimenting this problem ?

> Forward mapping and db types
> ----------------------------
>
>                 Key: NH-2647
>                 URL: http://216.121.112.228/browse/NH-2647
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.0.0.GA
>            Reporter: David Popiashvili
>            Priority: Minor
>         Attachments: NHibernateTest.rar
>
>
> When we create database from our *.hbm mapping files, some of the data types are not mapped correctly to the db. For example, NHibernate ignores Precision and Scale properties for decimal type. Also there's strange behavior with AnsiString, for example this property
> <property name="Username" length="15" type="AnsiString" /> is mapped as nvarchar(1) on the database, shouldn't it be varchar(15)?
> We are using .NET 4, NHibernate 3.0 and SQL Server 2008

-- 
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-2655) DbType.Double should be float(53) instead of DOUBLE PRECISION in the SQL-Severer2000 Dialect

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

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

Fabio Maulo closed NH-2655.
---------------------------

    Resolution: External Issue

> DbType.Double should be float(53) instead of DOUBLE PRECISION in the SQL-Severer2000 Dialect
> --------------------------------------------------------------------------------------------
>
>                 Key: NH-2655
>                 URL: http://216.121.112.228/browse/NH-2655
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: DataProviders / Dialects
>    Affects Versions: 3.2.0Alpha2
>            Reporter: Nils Andresen
>
> I am using NH to map c#-double values into SQL Server as floats. Everything works perfectly fine, however recently I tried running the SchemaValidator.
> SchemaValidator fails:
> Found: float, Expected DOUBLE PRECISION
> Creating the tables using DOUBLE PRECISION works, but SQL Server will report the columns as float
> The code for src/NHibernate/Dialect/MsSql2000Dialect.cs states 
> RegisterColumnType(DbType.Double, "DOUBLE PRECISION"); //synonym for FLOAT(53)
> IMO it would be better here to use the "real" type (float) istead of it's synonym.

-- 
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-2656) First/FirstOrDefault Doesn't Work

[Lee T. (JIRA) <nh...@gm...>]

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

Lee Timmins commented on NH-2656:
---------------------------------

Please note that i should have put the priority as Major as this issue is abit of a show stopper for me and i'm sure many others.  Since my last bug was resolved so quickly i have added a few of my other edge cases to help make the NHibernate Linq provider as good as possible.

Also note that the same issue arrises when using First/FirstOrDefault within a where clause, see the following tests:

[TestMethod]
public void Where_First() {
    var result = _session.Query<Post>()
        .Where(p => p.Comments.OrderBy(c => c.CommentID).First().IsSpam)
        .ToList();

    Assert.AreEqual(2, result.Count);
}

[TestMethod]
public void Where_FirstOrDefault() {
    var result = _session.Query<Post>()
        .Where(p => p.Comments.OrderBy(c => c.CommentID).FirstOrDefault(c => c.IsSpam).CommentID == 1)
        .ToList();
    var result2 = _session.Query<Post>()
        .Where(p => p.Comments.OrderBy(c => c.CommentID).FirstOrDefault(c => c.Type == CommentTypes.Anonymous) == null)
        .ToList();

    Assert.AreEqual(1, result.Count);
    Assert.AreEqual(3, result2.Count);
}

While these tests didn't pass in the old provider either it would be great if the new provider supported them.  Thanks

> First/FirstOrDefault Doesn't Work
> ---------------------------------
>
>                 Key: NH-2656
>                 URL: http://216.121.112.228/browse/NH-2656
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.1.0
>            Reporter: Lee Timmins
>
> I have the following tests:
> [TestMethod]
> public void First() {
>     var result = _session.Query<Post>()
>         .OrderBy(p => p.Date)
>         .First(p => p.Comments.Count == 1);
>     Assert.AreEqual(1, result.PostID);
> }
> [TestMethod]
> public void FirstOrDefault() {
>     var result = _session.Query<Post>()
>         .OrderBy(p => p.Date)
>         .FirstOrDefault(p => p.Comments.Count == 1);
>     var result2 = _session.Query<Post>()
>         .OrderBy(p => p.Date)
>         .FirstOrDefault(p => p.Comments.Count == 10);
>     Assert.AreEqual(1, result.PostID);
>     Assert.IsNull(result2);
> }
> They both worked fine in the old Linq provider (changing Query to Linq) but in version 3.1 it throws the error:
> Test method NHibernate3_1.UnitTest.First(OrDefault) threw exception: 
> System.InvalidOperationException: Sequence contains no elements

-- 
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