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

[nhibernate-issues] [NHJIRA] Commented: (NH-2632) Lazy Properties Causing An Exception If Containing Class Is Set To Not Lazy

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

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

Ricardo Peres commented on NH-2632:
-----------------------------------

ModelMapper mapper = new ModelMapper(); 
mapper.Class<Customer>(ca => 
{ 
        ca.Table("`CUSTOMER`"); 
        ca.Lazy(false); 
        ca.Id(x => x.Id, map => 
        { 
                map.Column("`ID`"); 
                map.Generator(new HiLoWithSuffixIdGenerator(), g => g.Params(new 
{ max_lo = "1000" })); 
        }); 
        ca.NaturalId(x => x.Property(c => c.Name)); 
        ca.Property(x => x.Name, p => 
        { 
                p.NotNullable(true); 
                p.Column("`NAME`"); 
        }); 
        ca.Property(x => x.Address, p => 
        { 
                p.NotNullable(false); 
                p.Lazy(true); 
                p.Column("`ADDRESS`"); 
        }); 
        ca.Set(c => c.Orders, c => 
        { 
                c.Key(x => x.Column("`CUSTOMERID`")); 
                c.Lazy(CollectionLazy.Lazy); 
                c.Inverse(true); 
                c.Cascade(Cascade.All); 
        }, c => c.OneToMany()); 
}); 

public class Customer 
{ 
        public virtual Int64 Id 
        { 
                get; 
                private set; 
        } 
        public virtual String Name 
        { 
                get; 
                set; 
        } 
        public virtual String Address 
        { 
                get; 
                set; 
        } 
        public virtual IEnumerable<Order> Orders 
        { 
                get; 
                private set; 
        } 
} 

public class Order
{
	public virtual Int32 Id
	{
		get;
		private set;
	}

	public virtual DateTime Date
	{
		get;
		set;
	}

	public virtual Customer Customer
	{
		get;
		set;
	}
}

> Lazy Properties Causing An Exception If Containing Class Is Set To Not Lazy
> ---------------------------------------------------------------------------
>
>                 Key: NH-2632
>                 URL: http://216.121.112.228/browse/NH-2632
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Ricardo Peres
>
> As discussed in NHibernate-Development (http://groups.google.com/group/nhibernate-development/browse_thread/thread/703b76e5b82595d6), when a property is set to lazy but its containing class is set to not lazy, an exception occurs when loading an entity of this 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] Created: (NH-2632) Lazy Properties Causing An Exception If Containing Class Is Set To Not Lazy

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

Lazy Properties Causing An Exception If Containing Class Is Set To Not Lazy
---------------------------------------------------------------------------

                 Key: NH-2632
                 URL: http://216.121.112.228/browse/NH-2632
             Project:  NHibernate
          Issue Type: Bug
          Components: Core
    Affects Versions: 3.1.0
            Reporter: Ricardo Peres


As discussed in NHibernate-Development (http://groups.google.com/group/nhibernate-development/browse_thread/thread/703b76e5b82595d6), when a property is set to lazy but its containing class is set to not lazy, an exception occurs when loading an entity of this 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] Created: (NH-2631) Problem in executing stored procedure with NHibernate 3 as well.

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

Problem in executing stored procedure with NHibernate 3 as well.
----------------------------------------------------------------

                 Key: NH-2631
                 URL: http://216.121.112.228/browse/NH-2631
             Project:  NHibernate
          Issue Type: Bug
          Components: Core
    Affects Versions: 3.0.0.GA
            Reporter: Anupam Mishra
            Priority: Major
         Attachments: Stored Procedure Problem.txt

Following is my Stored Procedure:
create or replace PROCEDURE GETPERSONTEST (io_cursor   IN OUT   sys_refcursor) 
IS
BEGIN 
OPEN io_cursor FOR 
      SELECT EMP_ID,EMP_NAME,EMP_PASSWORD,TEAM_ASSOCIATED_WITH,IS_CAPTAIN,NO_OF_MOM,BALANCE  FROM employee  ; 
END GETPERSONTEST; 

Nhibernate Mapping:

 <sql-query name="selemployee" callable="true">
    <return class="DomainObject.Employee,DomainObject" >
      <return-property name="EmployeeId" column="Emp_ID"/>     
      <return-property name="EmployeeName" column="EMP_NAME"/>
      <return-property name="EmployeePassword" column="EMP_PASSWORD"/>
      <return-property name="TeamAssociatedWith" column="TEAM_ASSOCIATED_WITH"/>
      <return-property name="IsCaptain" column="IS_CAPTAIN"/>
      <return-property name="NumberOfMOM" column="NO_OF_MOM"/>
      <return-property name="Balance" column="BALANCE"/>
    </return>
  {call GETPERSONTEST(?)}
  </sql-query>

Problem in Executing throwing following exception 

Exception stack trace is attached.

 could not execute query
[ {call GETPERSONTEST(@p0)} ]


It will be a great help if suggest some approach to make it work.

As this problem is coming with every version of NHibernate.Create ,Update and Delete is working fine only facing this problem in case of select.



-- 
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-2630) Truncate SQL parameter logging of very long strings

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

Truncate SQL parameter logging of very long strings
---------------------------------------------------

                 Key: NH-2630
                 URL: http://216.121.112.228/browse/NH-2630
             Project:  NHibernate
          Issue Type: Improvement
          Components: Core
    Affects Versions: 3.1.0
            Reporter: cremor
            Priority: Minor


Similar to NH-2518 it would be great if very long strings (that would be mapped to a CLOB, VARCHAR(MAX) or a similar column) would be truncated in the SQL parameter logging.

A good max length would be 4000 chars in my opinion.

-- 
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-2629) Typedef reference in composite key (in hbm files)

[Massimiliano A. (JIRA) <nh...@gm...>]

Typedef reference in composite key (in hbm files)
-------------------------------------------------

                 Key: NH-2629
                 URL: http://216.121.112.228/browse/NH-2629
             Project:  NHibernate
          Issue Type: Bug
          Components: Core
    Affects Versions: 3.0.0.GA
            Reporter: Massimiliano Alberti


I'm using a UserType. I have a typedef at the beginning of the file, like this:

    <?xml version="1.0" encoding="utf-8" ?>
    <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" default-lazy="false">
        <typedef name="AnsiStringTrimmed" class="Utils.AnsiStringTrimmed, Utils" />

If I reference AnsiStringTrimmed in a property it works, like this:

    <property name="Field" type="AnsiStringTrimmed" not-null="true" length="6" />

But if I try to use it in a key-property element it doesn't work, like this:

    <composite-id name="PKey" class="Project.PKey, Project">
        <key-property name="Field" type="AnsiStringTrimmed" length="3" />

I get a MappingException like this: Could not determine type for: AnsiStringTrimmed, for columns: NHibernate.Mapping.Column(Field). 
If I use the full name of the usertype it works correctly (Utils.AnsiStringTrimmed, Utils)



-- 
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-2628) Fails to create proxy for class with method that has argument "ref of Dictionary<string, string>"

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

Fails to create proxy for class with method that has argument "ref of Dictionary<string, string>"
-------------------------------------------------------------------------------------------------

                 Key: NH-2628
                 URL: http://216.121.112.228/browse/NH-2628
             Project:  NHibernate
          Issue Type: Bug
          Components: ByteCode providers
    Affects Versions: 3.2.0
            Reporter: Pavel Peker
            Priority: Critical


fails in DefaultMethodEmitter.cs 

private static void SaveRefArguments(ILGenerator IL, ParameterInfo[] parameters)

when class has method with parameter "ref Dictionary<string, string>"

typeName = typeName.Replace("&", "");
System.Type unboxedType = System.Type.GetType(typeName);
IL.Emit(OpCodes.Unbox_Any, unboxedType);

System.Type.GetType(typeName) returns null in this case. Changed code above into 

string typeName = param.ParameterType.FullName;

instead

string typeName = param.ParameterType.Name;

and it fixed problem.

-- 
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-2627) Cloning subcriteria loses WithClause

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

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

Fabio Maulo updated NH-2627:
----------------------------

    Component/s:     (was: -------------)
                 Core

> Cloning subcriteria loses WithClause
> ------------------------------------
>
>                 Key: NH-2627
>                 URL: http://216.121.112.228/browse/NH-2627
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.2.0
>            Reporter: Vitaliy Litovskiy
>         Attachments: subcriteria_clone_fix.patch
>
>
> Method CloneSubcriteria in Subcriteria class doesn't clone the original WithClause.
> steps to reproduce in pseudo code:
> var criteria = DetachedCriteria.For<Model>();
> criteria.AddAlias("Collection", "item", JoinType.LeftOuterJoin, Restrictions.Eq("item.Property", "somve value"))
> var cloneCriteria = CriteriaTransformer.Clone(criteria);
> As a result criteria and cloneCriteria will return different results. This is cause by additional ON conditions for JOIN are lost in the SQL.
> It seems that i've found how to fix the issue, but i haven't set up the development environment yet and cant build NHibernate solution and run tests. The possible patch 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-2627) Cloning subcriteria loses WithClause

[Vitaliy L. (JIRA) <nh...@gm...>]

Cloning subcriteria loses WithClause
------------------------------------

                 Key: NH-2627
                 URL: http://216.121.112.228/browse/NH-2627
             Project:  NHibernate
          Issue Type: Bug
          Components: -------------
    Affects Versions: 3.2.0
            Reporter: Vitaliy Litovskiy
         Attachments: subcriteria_clone_fix.patch

Method CloneSubcriteria in Subcriteria class doesn't clone the original WithClause.

steps to reproduce in pseudo code:
var criteria = DetachedCriteria.For<Model>();
criteria.AddAlias("Collection", "item", JoinType.LeftOuterJoin, Restrictions.Eq("item.Property", "somve value"))

var cloneCriteria = CriteriaTransformer.Clone(criteria);

As a result criteria and cloneCriteria will return different results. This is cause by additional ON conditions for JOIN are lost in the SQL.

It seems that i've found how to fix the issue, but i haven't set up the development environment yet and cant build NHibernate solution and run tests. The possible patch 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-2626) LinqExtensionMethods.Query<T> implements wrong NhQueryable<T>

[Maximilian H. R. (JIRA) <nh...@gm...>]

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

Maximilian Haru Raditya commented on NH-2626:
---------------------------------------------

Thanks, Patrick! It's such a quick response :).

> LinqExtensionMethods.Query<T> implements wrong NhQueryable<T>
> -------------------------------------------------------------
>
>                 Key: NH-2626
>                 URL: http://216.121.112.228/browse/NH-2626
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.1.0
>            Reporter: Kenneth Siewers Møller
>            Assignee: Patrick Earl
>             Fix For: 3.2.0
>
>
> According to this post http://groups.google.com/group/castle-project-devel/browse_thread/thread/ac90148a8d4c8477
> It seems it's a bug in NHibernate LinqExtensionMethods implementation. If 
> you take a look at LinqExtensionMethods.Query<T>(this ISession) 
> implementation in NHibernate souce code, it's currently implemented like 
> this:
> public static IQueryable<T> Query<T>(this ISession session)
> { 
>     return new NhQueryable<T>(session as ISessionImplementor); 
> } 
> when it should be implemented like this: 
> public static IQueryable<T> Query<T>(this ISession session) 
> { 
>     return new NhQueryable<T>(*session.GetSessionImplementation()*); 
> } 
> The explanation is that in NHibernate SessionImpl, it inherits from 
> ISessionImplementor, while in NHibernateFacility SessionDelegate, it doesn't 
> inherit from ISessionImplementor. That's why when SessionDelegate cast back 
> to ISessionImplementor, it became null. 

-- 
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-2626) LinqExtensionMethods.Query<T> implements wrong NhQueryable<T>

[Patrick E. (JIRA) <nh...@gm...>]

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

Patrick Earl commented on NH-2626:
----------------------------------

I also searched for any other cases where this sort of cast was present and found none.

> LinqExtensionMethods.Query<T> implements wrong NhQueryable<T>
> -------------------------------------------------------------
>
>                 Key: NH-2626
>                 URL: http://216.121.112.228/browse/NH-2626
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.1.0
>            Reporter: Kenneth Siewers Møller
>            Assignee: Patrick Earl
>             Fix For: 3.2.0
>
>
> According to this post http://groups.google.com/group/castle-project-devel/browse_thread/thread/ac90148a8d4c8477
> It seems it's a bug in NHibernate LinqExtensionMethods implementation. If 
> you take a look at LinqExtensionMethods.Query<T>(this ISession) 
> implementation in NHibernate souce code, it's currently implemented like 
> this:
> public static IQueryable<T> Query<T>(this ISession session)
> { 
>     return new NhQueryable<T>(session as ISessionImplementor); 
> } 
> when it should be implemented like this: 
> public static IQueryable<T> Query<T>(this ISession session) 
> { 
>     return new NhQueryable<T>(*session.GetSessionImplementation()*); 
> } 
> The explanation is that in NHibernate SessionImpl, it inherits from 
> ISessionImplementor, while in NHibernateFacility SessionDelegate, it doesn't 
> inherit from ISessionImplementor. That's why when SessionDelegate cast back 
> to ISessionImplementor, it became null. 

-- 
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-2626) LinqExtensionMethods.Query<T> implements wrong NhQueryable<T>

[Patrick E. (JIRA) <nh...@gm...>]

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

Patrick Earl resolved NH-2626.
------------------------------

       Resolution: Fixed
    Fix Version/s: 3.2.0

> LinqExtensionMethods.Query<T> implements wrong NhQueryable<T>
> -------------------------------------------------------------
>
>                 Key: NH-2626
>                 URL: http://216.121.112.228/browse/NH-2626
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.1.0
>            Reporter: Kenneth Siewers Møller
>            Assignee: Patrick Earl
>             Fix For: 3.2.0
>
>
> According to this post http://groups.google.com/group/castle-project-devel/browse_thread/thread/ac90148a8d4c8477
> It seems it's a bug in NHibernate LinqExtensionMethods implementation. If 
> you take a look at LinqExtensionMethods.Query<T>(this ISession) 
> implementation in NHibernate souce code, it's currently implemented like 
> this:
> public static IQueryable<T> Query<T>(this ISession session)
> { 
>     return new NhQueryable<T>(session as ISessionImplementor); 
> } 
> when it should be implemented like this: 
> public static IQueryable<T> Query<T>(this ISession session) 
> { 
>     return new NhQueryable<T>(*session.GetSessionImplementation()*); 
> } 
> The explanation is that in NHibernate SessionImpl, it inherits from 
> ISessionImplementor, while in NHibernateFacility SessionDelegate, it doesn't 
> inherit from ISessionImplementor. That's why when SessionDelegate cast back 
> to ISessionImplementor, it became null. 

-- 
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-2626) LinqExtensionMethods.Query<T> implements wrong NhQueryable<T>

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

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

Fabio Maulo updated NH-2626:
----------------------------

    Priority: Trivial  (was: Major)

> LinqExtensionMethods.Query<T> implements wrong NhQueryable<T>
> -------------------------------------------------------------
>
>                 Key: NH-2626
>                 URL: http://216.121.112.228/browse/NH-2626
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.1.0
>            Reporter: Kenneth Siewers Møller
>            Assignee: Patrick Earl
>
> According to this post http://groups.google.com/group/castle-project-devel/browse_thread/thread/ac90148a8d4c8477
> It seems it's a bug in NHibernate LinqExtensionMethods implementation. If 
> you take a look at LinqExtensionMethods.Query<T>(this ISession) 
> implementation in NHibernate souce code, it's currently implemented like 
> this:
> public static IQueryable<T> Query<T>(this ISession session)
> { 
>     return new NhQueryable<T>(session as ISessionImplementor); 
> } 
> when it should be implemented like this: 
> public static IQueryable<T> Query<T>(this ISession session) 
> { 
>     return new NhQueryable<T>(*session.GetSessionImplementation()*); 
> } 
> The explanation is that in NHibernate SessionImpl, it inherits from 
> ISessionImplementor, while in NHibernateFacility SessionDelegate, it doesn't 
> inherit from ISessionImplementor. That's why when SessionDelegate cast back 
> to ISessionImplementor, it became null. 

-- 
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] Assigned: (NH-2624) MultiCriteria does not work with criteria created using JoinQueryOver

[Richard B. (JIRA) <nh...@gm...>]

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

Richard Brown reassigned NH-2624:
---------------------------------

    Assignee: Richard Brown

> MultiCriteria does not work with criteria created using JoinQueryOver
> ---------------------------------------------------------------------
>
>                 Key: NH-2624
>                 URL: http://216.121.112.228/browse/NH-2624
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: xelibrion
>            Assignee: Richard Brown
>            Priority: Critical
>
> I've got exception 
> System.InvalidCastException: Unable to cast object of type 'Subcriteria' to type 'NHibernate.Impl.CriteriaImpl'.
>    at NHibernate.Impl.MultiCriteriaImpl.CreateCriteriaLoaders() in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\MultiCriteriaImpl.cs:line 287
>    at NHibernate.Impl.MultiCriteriaImpl.List() in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\MultiCriteriaImpl.cs:line 73
> in code
> var queryOver = Session.QueryOver<Post>()
> 				.Fetch(x => x.Author).Eager
> 				.Fetch(x => x.Blog).Eager
> 				.JoinQueryOver(x => x.SearchRequests)
> 				.Where(x => x.Id == context.SearchRequestId)
> 				.TransformUsing(Transformers.DistinctRootEntity)
>                                 .Skip(context.PageIndex*pageSize)
> 				.Take(pageSize);
> Session.CreateMultiCriteria()
> 				.Add(queryOver.UnderlyingCriteria)
> 				.Add(queryOver.ToRowCountQuery().UnderlyingCriteria)
> 				.List();
> I've found workaround using JoinAlias

-- 
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] Assigned: (NH-2626) LinqExtensionMethods.Query<T> implements wrong NhQueryable<T>

[Patrick E. (JIRA) <nh...@gm...>]

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

Patrick Earl reassigned NH-2626:
--------------------------------

    Assignee: Patrick Earl

> LinqExtensionMethods.Query<T> implements wrong NhQueryable<T>
> -------------------------------------------------------------
>
>                 Key: NH-2626
>                 URL: http://216.121.112.228/browse/NH-2626
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.1.0
>            Reporter: Kenneth Siewers Møller
>            Assignee: Patrick Earl
>            Priority: Major
>
> According to this post http://groups.google.com/group/castle-project-devel/browse_thread/thread/ac90148a8d4c8477
> It seems it's a bug in NHibernate LinqExtensionMethods implementation. If 
> you take a look at LinqExtensionMethods.Query<T>(this ISession) 
> implementation in NHibernate souce code, it's currently implemented like 
> this:
> public static IQueryable<T> Query<T>(this ISession session)
> { 
>     return new NhQueryable<T>(session as ISessionImplementor); 
> } 
> when it should be implemented like this: 
> public static IQueryable<T> Query<T>(this ISession session) 
> { 
>     return new NhQueryable<T>(*session.GetSessionImplementation()*); 
> } 
> The explanation is that in NHibernate SessionImpl, it inherits from 
> ISessionImplementor, while in NHibernateFacility SessionDelegate, it doesn't 
> inherit from ISessionImplementor. That's why when SessionDelegate cast back 
> to ISessionImplementor, it became null. 

-- 
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-2626) LinqExtensionMethods.Query<T> implements wrong NhQueryable<T>

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

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

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

This applies to both Query<T>(this ISession session) as well as Query<T>(this IStatelessSession session).

> LinqExtensionMethods.Query<T> implements wrong NhQueryable<T>
> -------------------------------------------------------------
>
>                 Key: NH-2626
>                 URL: http://216.121.112.228/browse/NH-2626
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.1.0
>            Reporter: Kenneth Siewers Møller
>            Priority: Major
>
> According to this post http://groups.google.com/group/castle-project-devel/browse_thread/thread/ac90148a8d4c8477
> It seems it's a bug in NHibernate LinqExtensionMethods implementation. If 
> you take a look at LinqExtensionMethods.Query<T>(this ISession) 
> implementation in NHibernate souce code, it's currently implemented like 
> this:
> public static IQueryable<T> Query<T>(this ISession session)
> { 
>     return new NhQueryable<T>(session as ISessionImplementor); 
> } 
> when it should be implemented like this: 
> public static IQueryable<T> Query<T>(this ISession session) 
> { 
>     return new NhQueryable<T>(*session.GetSessionImplementation()*); 
> } 
> The explanation is that in NHibernate SessionImpl, it inherits from 
> ISessionImplementor, while in NHibernateFacility SessionDelegate, it doesn't 
> inherit from ISessionImplementor. That's why when SessionDelegate cast back 
> to ISessionImplementor, it became null. 

-- 
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-2596) changes made in IPreInsert/UpdateEventListener are not persisted into DB on inherited classes

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

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

Scott Findlater commented on NH-2596:
-------------------------------------

Fabio, I rasied NH-2617 which was closed with this being a duplicate - sorry about that.  

However, I still don't feel I have a conclusion.  You say "pre-insert and pre-update listeners are not intended to be used to change the values of the entity. Instead they should be used to check-values (for that reason they return "veto")." but how come if an inherited entity which has just 1 property modified prior to the PreUpdate listener, will have all modifications made within the PreUpdate listener persisted to the database (even with dynamic-update set to true) vs an inherited entity which only has properties modified within the PreUpdate listener will not result in changes being persisted?

Does this behaviour not demonstrate an issue in NHibernate where entity's modified within PreUpdate listeners can change data and behave correctly?  Also Ayende's very popular audit trail blog post which uses PreUpdate and PreInsert listeners (http://ayende.com/Blog/archive/2009/04/29/nhibernate-ipreupdateeventlistener-amp-ipreinserteventlistener.aspx) - does that mean this approach is wrong?

This is not intended to be a complaint at NHibernate, just I really want to understand the event model correctly.

> changes made in IPreInsert/UpdateEventListener are not persisted into DB on inherited classes
> ---------------------------------------------------------------------------------------------
>
>                 Key: NH-2596
>                 URL: http://216.121.112.228/browse/NH-2596
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.0.0.Alpha3
>            Reporter: Filip Kinsky
>            Priority: Major
>         Attachments: NHListenerTest.zip, NHListenerTest_NH31.zip
>
>
> We're logging modification date in few of our persisted classes using simple 
> interface and basic IPreInsert/UpdateEventListener implementation which uses 
> this code to set LastModified field: 
> var trackable = entity as ITrackModificationDate; 
> if (trackable != null) 
> { 
>   trackable.LastModified = DateTime.Now; 
>   persister.SetPropertyValue(state, "LastModified", trackable.LastModified); 
> } 
> This works for basic classes without any inheritance hierarchy, but when I 
> map inherited classes (LastModified field implemented by the hierarchy 
> root) and update some property which exists just in the inherited class, the 
> listener is triggered, but the modified LastModified property value is not 
> being persisted into database. I isolated the problem and implemented 
> attached failing test, but I'm not able to figure out what should I do in 
> the listener to force NH to update the DB properly.
> Test classes: 
> public class Thing : ITrackModificationDate 
> { 
>   public virtual long Id { get; set; } 
>   public virtual DateTime LastModified { get; set; } 
> } 
> public class InheritedThing: Thing 
> { 
> public virtual string SomeText { get; set; } 
> } 
> public class ThingMap : ClassMap<Thing> 
> { 
> public ThingMap() 
> { 
>   Id(x => x.Id).GeneratedBy.Assigned(); 
>   Map(x => x.LastModified); 
> } 
> } 
> public class InheritedThingMap: SubclassMap<InheritedThing> 
> { 
> public InheritedThingMap() 
> { 
>  Map(x => x.SomeText); 
> } 
> } 
> Failing test: 
> [Fact] 
> public void InheritedThing_LastModified_Should_BeSetOnUpdate() 
> { 
>   var t = new InheritedThing {Id = 1, SomeText = "aa"}; 
>   session.Save(t); 
>   session.Flush(); 
>   session.Clear(); 
>   
>   Thread.Sleep(1000); 
>   t = session.Get<InheritedThing>(1L); 
>   t.SomeText = "bb"; 
>   session.Update(t); 
>   session.Flush(); 
>   session.Clear(); 
>   
>   t = session.Get<InheritedThing>(1L); 
>   Assert.True(DateTime.Now.Subtract(t.LastModified).TotalSeconds < 1); //this fails - LastModified property isn't updated in DB 
> }

-- 
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-2626) LinqExtensionMethods.Query<T> implements wrong NhQueryable<T>

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

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

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

As a matter of fact, the remarks in the documentations actually states the following about GetSessionImplementation():

"This method is provided in order to get the NHibernate implementation of the session from wrapper implementions. Implementors of the ISession interface should return the NHibernate implementation of this method."

So I believe this is quite a serious bug, as any wrapper basically won't work.

> LinqExtensionMethods.Query<T> implements wrong NhQueryable<T>
> -------------------------------------------------------------
>
>                 Key: NH-2626
>                 URL: http://216.121.112.228/browse/NH-2626
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.1.0
>            Reporter: Kenneth Siewers Møller
>            Priority: Major
>
> According to this post http://groups.google.com/group/castle-project-devel/browse_thread/thread/ac90148a8d4c8477
> It seems it's a bug in NHibernate LinqExtensionMethods implementation. If 
> you take a look at LinqExtensionMethods.Query<T>(this ISession) 
> implementation in NHibernate souce code, it's currently implemented like 
> this:
> public static IQueryable<T> Query<T>(this ISession session)
> { 
>     return new NhQueryable<T>(session as ISessionImplementor); 
> } 
> when it should be implemented like this: 
> public static IQueryable<T> Query<T>(this ISession session) 
> { 
>     return new NhQueryable<T>(*session.GetSessionImplementation()*); 
> } 
> The explanation is that in NHibernate SessionImpl, it inherits from 
> ISessionImplementor, while in NHibernateFacility SessionDelegate, it doesn't 
> inherit from ISessionImplementor. That's why when SessionDelegate cast back 
> to ISessionImplementor, it became null. 

-- 
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-2626) LinqExtensionMethods.Query<T> implements wrong NhQueryable<T>

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

LinqExtensionMethods.Query<T> implements wrong NhQueryable<T>
-------------------------------------------------------------

                 Key: NH-2626
                 URL: http://216.121.112.228/browse/NH-2626
             Project:  NHibernate
          Issue Type: Bug
          Components: Linq Provider
    Affects Versions: 3.1.0
            Reporter: Kenneth Siewers Møller
            Priority: Major


According to this post http://groups.google.com/group/castle-project-devel/browse_thread/thread/ac90148a8d4c8477

It seems it's a bug in NHibernate LinqExtensionMethods implementation. If 
you take a look at LinqExtensionMethods.Query<T>(this ISession) 
implementation in NHibernate souce code, it's currently implemented like 
this:

public static IQueryable<T> Query<T>(this ISession session)
{ 
    return new NhQueryable<T>(session as ISessionImplementor); 
} 

when it should be implemented like this: 

public static IQueryable<T> Query<T>(this ISession session) 
{ 
    return new NhQueryable<T>(*session.GetSessionImplementation()*); 
} 

The explanation is that in NHibernate SessionImpl, it inherits from 
ISessionImplementor, while in NHibernateFacility SessionDelegate, it doesn't 
inherit from ISessionImplementor. That's why when SessionDelegate cast back 
to ISessionImplementor, it became null. 

-- 
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-2049) Joined subclass filtering, invalid SQL generated

[Sergio A. (JIRA) <nh...@gm...>]

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

Sergio Alvarez commented on NH-2049:
------------------------------------

Still happening in Hibernate 3.1.0.4000

> Joined subclass filtering, invalid SQL generated
> ------------------------------------------------
>
>                 Key: NH-2049
>                 URL: http://216.121.112.228/browse/NH-2049
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.1.2.GA
>            Reporter: Ville Häkli
>            Priority: Major
>         Attachments: NH2049.zip
>
>
> We have following entities:
>  - Customer, which has deleted property
>  - IndividualCustomer, which is inherited from Customer and has one-to-one (mapped as many-to-one with unique=true) relation to Person
>  - Person which has IndividualCustomer property as one-to-one with property-ref to IndividualCustomer's Person property
> If we enable filter, which filters deleted customers by deleted property and get person with criteria, following SQL is generated:
> SELECT ...
> FROM   Person this_
>   left outer join IndividualCustomer individual2_ on this_.Id = individual2_.PersonID and individual2_1_.Deleted = 1
>   left outer join Customer individual2_1_ on individual2_.IndividualCustomerID = individual2_1_.Id
> This obviously fails because the "filtering condition" (individual2_1_.Deleted = 1) is in wrong join.

-- 
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-2583) Query with || operator and navigations (many-to-one) creates wrong joins

[Harald M. M. (J. <nh...@gm...>]

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

Harald M. Müller updated NH-2583:
---------------------------------

    Attachment: NH-2583f.diff

"Outer join semantics" ((||-4) semantics) implemented, including inner joins. Right now, there is no description of (a) test concepts [different to previous versions for exceptional cases]; (b) algorithms - overall and for inner join optimization; (c) design/code.

> Query with || operator and navigations (many-to-one) creates wrong joins
> ------------------------------------------------------------------------
>
>                 Key: NH-2583
>                 URL: http://216.121.112.228/browse/NH-2583
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.1.0
>            Reporter: Harald M. Müller
>            Assignee: Patrick Earl
>            Priority: Critical
>         Attachments: LogicalOperatorsInNHibernateLinq.txt, NH-2583a.diff, NH-2583b.diff, NH-2583c.diff, NH-2583d.diff, NH-2583e.diff, NH-2583f.diff, NH2583.7z, NHib3.0.0Or.zip
>
>
> The following query
>                     var result = session.Query<MyBO>()
>                         .Where(bo =>
>                                 (bo.BO1 != null && bo.BO1.I2 == 101) ||
>                                 (bo.BO2 != null && bo.BO2.J2 == 203)
>                               )
>                         ;
>                     result.ToList();
> creates the following SQL on SQL Server 2008 (with .Net 4.0, MsSql2008Dialect):
> exec sp_executesql N'select mybo0_.Id as Id0_, mybo0_.Name as Name0_, mybo0_.BO1Key as BO3_0_, mybo0_.OtherBO1Key as OtherBO4_0_, mybo0_.BO2Key as BO5_0_ from MyBO mybo0_, MyRef1 myref1x1_, MyRef2 myref2x2_ where mybo0_.BO1Key=myref1x1_.Id and mybo0_.BO2Key=myref2x2_.Id and ((mybo0_.BO1Key is not null) and myref1x1_.I2=@p0 or (mybo0_.BO2Key is not null) and myref2x2_.J2=@p1)',N'@p0 int,@p1 int',@p0=101,@p1=203
> or, formatted:
> SELECT mybo0_.id          AS id0_,
>        mybo0_.name        AS name0_,
>        mybo0_.bo1key      AS bo3_0_,
>        mybo0_.otherbo1key AS otherbo4_0_,
>        mybo0_.bo2key      AS bo5_0_
> FROM   mybo mybo0_,
>        myref1 myref1x1_,
>        myref2 myref2x2_
> WHERE  mybo0_.bo1key = myref1x1_.id                  -- inner (table) join
>        AND mybo0_.bo2key = myref2x2_.id              -- also inner (table) join
>        AND ( ( mybo0_.bo1key IS NOT NULL )
>              AND myref1x1_.i2 = @p0
>               OR ( mybo0_.bo2key IS NOT NULL )
>                  AND myref2x2_.j2 = @p1 )  
> This is wrong if the reference to ref1 or ref2 is null. The attachment contains a small project that shows the problem.
> AFAIK, the problem has been always present when using HQL navigations (a.b.c....); it is - somewhat implicitly - documented in seciotn 13.7.:
>     Compound path expressions make the where clause extremely powerful. Consider:
>        from Eg.Cat cat where cat.Mate.Name is not null
>     This query translates to an SQL query with a table (inner) join.
> In HQL, one can claim that this is "a feature" (and the workaround is to use manual JOINs). With Linq, this is no longer possible - the semantics of the || operator should be correctly implemented, shouldn't it? Therefore, I dared to mark this bug as "Critical".
> (... or - please - show me that I'm wrong and that || + navigation work as expected!).
> Remark: In our project, which started with NHib 0.99 six years ago, we(I) wrote a complete expression framework akin to Linq (but only with conditions, not with expressions). When we found this problem, I rewrote the HQL builder so that it then created (and still creates) correct INNER or OUTER JOINs, depending on the expression tree (one has to consider Is-Null/Is-Not-Null operators and Not nodes above these, as far as I remember ... I'd have to look into our code).

-- 
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-2621) Failing Linq OrderBy clause.

[Jerome H. (JIRA) <nh...@gm...>]

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

Jerome Haltom commented on NH-2621:
-----------------------------------

Okay. I figured out what theissue is, and exactly what the bug in NHibernate is. And it is a bug.


            var q = new NhQueryProvider(CurrentDataSession.NhSession).CreateQuery<Data.Core.BenefitSchedule>(
                Expression.Call(
                    typeof(Queryable),
                    "OrderBy",
                    new Type[] { typeof(Data.Core.BenefitSchedule), typeof(int) },
                    Expression.Call(
                        typeof(Queryable),
                        "Where",
                        new Type[] { typeof(Data.Core.BenefitSchedule) },
                        CurrentDataSession.Query<Data.Core.BenefitSchedule>().Expression,
                        Expression.Lambda(
                            Expression.Equal(
                                Expression.Property(
                                    Expression.Variable(
                                        typeof(Data.Core.BenefitSchedule),
                                        "it"),
                                    "Id"),
                                Expression.Constant(Guid.NewGuid())),
                            Expression.Parameter(typeof(Data.Core.BenefitSchedule), "it"))),
                    Expression.Lambda(
                        Expression.Property(
                            Expression.Variable(
                                typeof(Data.Core.BenefitSchedule),
                                "p"),
                            "IntId"),
                        Expression.Parameter(typeof(Data.Core.BenefitSchedule), "p"))));


This hand built expression tree breaks. It's a simple order by and where clause. The issue is that the second Lambda's Parameter's name is "p". Not "it." I can work around this for now by rewriting the expression tree.

It is however a bug in NHibernate's Linq provider. The parameter name should only be valid for the scope of the parameter, which in this case is the Lambda of the OrderBy clause. NHibernate just isn't resolving it properly.

> Failing Linq OrderBy clause.
> ----------------------------
>
>                 Key: NH-2621
>                 URL: http://216.121.112.228/browse/NH-2621
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.0.0.GA
>            Reporter: Jerome Haltom
>
> This IQueryable Expression is throwing an error at Ast.ANTLR.Util.LiteralProcessor, line 77. It is failing to parse p.IntId. Says it's not a constant. It's not. It's a property reference for an OrderBy. I'm not sure why it's trying to resolve it as a constant. This ANTLR code is nearly impossible for me to understand.
> .Call System.Linq.Queryable.OrderBy(
>     .Call System.Linq.Queryable.Where(
>         .Constant<NHibernate.Linq.NhQueryable`1[ISIS.Data.Core.BenefitSchedule]>(NHibernate.Linq.NhQueryable`1[ISIS.Data.Core.BenefitSchedule]),
>         '(.Lambda #Lambda1<System.Func`2[ISIS.Data.Core.BenefitSchedule,System.Boolean]>)),
>     '(.Lambda #Lambda2<System.Func`2[ISIS.Data.Core.BenefitSchedule,System.Int32]>))
> .Lambda #Lambda1<System.Func`2[ISIS.Data.Core.BenefitSchedule,System.Boolean]>(ISIS.Data.Core.BenefitSchedule $it) {
>     True && $it.Id == .Constant<System.Guid>(d44f4aac-2ec8-4afc-87e5-6ed5f8a0dfc8)
> }
> .Lambda #Lambda2<System.Func`2[ISIS.Data.Core.BenefitSchedule,System.Int32]>(ISIS.Data.Core.BenefitSchedule $p) {
>     $p.IntId
> }
> The expression string looks like: 
> .OrderBy(.Where(NHibernate.Linq.NhQueryable`1[ISIS.Data.Core.BenefitSchedule], Quote((it, ) => (AndAlso(p1, Guid.op_Equality(it.Id, p2)))), ), Quote((p, ) => (p.IntId)), )
> I don't see anything wrong with this, except maybe the name p?

-- 
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-2621) Failing Linq OrderBy clause.

[Jerome H. (JIRA) <nh...@gm...>]

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

Jerome Haltom commented on NH-2621:
-----------------------------------

I haven't been able to generate a test case. The Expression is being generated by WCF Data Services and a custom Linq ExpressionVisitor that I wrote to adapt NHibernate to WCF Data Services. When I code the Expression using the NhQueryProvider it works fine, but that ends up being slightly different.

There's a call in DotNode.cs called PrepareLhs which I believe is supposed to resolve the references for the left hand side of the p.IntId expression. That code returns a FromReferenceNode. The returned FromReferenceNode has no FromElement. The code proceeds from there and assumes that since it has no element, that it's a constant.

I'll keep digging and see if I can actually isolate the issue better... =/

> Failing Linq OrderBy clause.
> ----------------------------
>
>                 Key: NH-2621
>                 URL: http://216.121.112.228/browse/NH-2621
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Linq Provider
>    Affects Versions: 3.0.0.GA
>            Reporter: Jerome Haltom
>
> This IQueryable Expression is throwing an error at Ast.ANTLR.Util.LiteralProcessor, line 77. It is failing to parse p.IntId. Says it's not a constant. It's not. It's a property reference for an OrderBy. I'm not sure why it's trying to resolve it as a constant. This ANTLR code is nearly impossible for me to understand.
> .Call System.Linq.Queryable.OrderBy(
>     .Call System.Linq.Queryable.Where(
>         .Constant<NHibernate.Linq.NhQueryable`1[ISIS.Data.Core.BenefitSchedule]>(NHibernate.Linq.NhQueryable`1[ISIS.Data.Core.BenefitSchedule]),
>         '(.Lambda #Lambda1<System.Func`2[ISIS.Data.Core.BenefitSchedule,System.Boolean]>)),
>     '(.Lambda #Lambda2<System.Func`2[ISIS.Data.Core.BenefitSchedule,System.Int32]>))
> .Lambda #Lambda1<System.Func`2[ISIS.Data.Core.BenefitSchedule,System.Boolean]>(ISIS.Data.Core.BenefitSchedule $it) {
>     True && $it.Id == .Constant<System.Guid>(d44f4aac-2ec8-4afc-87e5-6ed5f8a0dfc8)
> }
> .Lambda #Lambda2<System.Func`2[ISIS.Data.Core.BenefitSchedule,System.Int32]>(ISIS.Data.Core.BenefitSchedule $p) {
>     $p.IntId
> }
> The expression string looks like: 
> .OrderBy(.Where(NHibernate.Linq.NhQueryable`1[ISIS.Data.Core.BenefitSchedule], Quote((it, ) => (AndAlso(p1, Guid.op_Equality(it.Id, p2)))), ), Quote((p, ) => (p.IntId)), )
> I don't see anything wrong with this, except maybe the name p?

-- 
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-2625) Implement Dialect Scope for Subselect

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

Implement Dialect Scope for Subselect
-------------------------------------

                 Key: NH-2625
                 URL: http://216.121.112.228/browse/NH-2625
             Project:  NHibernate
          Issue Type: Improvement
          Components: Core
    Affects Versions: 3.2.0
            Reporter: Ricardo Peres


It would be great if the new <subselect/> functionality could be scoped to a specific dialect or set of dialects, like <database-object/>.

-- 
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-2624) MultiCriteria does not work with criteria created using JoinQueryOver

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

MultiCriteria does not work with criteria created using JoinQueryOver
---------------------------------------------------------------------

                 Key: NH-2624
                 URL: http://216.121.112.228/browse/NH-2624
             Project:  NHibernate
          Issue Type: Bug
          Components: Core
    Affects Versions: 3.1.0
            Reporter: xelibrion
            Priority: Critical


I've got exception 

System.InvalidCastException: Unable to cast object of type 'Subcriteria' to type 'NHibernate.Impl.CriteriaImpl'.
   at NHibernate.Impl.MultiCriteriaImpl.CreateCriteriaLoaders() in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\MultiCriteriaImpl.cs:line 287
   at NHibernate.Impl.MultiCriteriaImpl.List() in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\MultiCriteriaImpl.cs:line 73

in code

var queryOver = Session.QueryOver<Post>()
				.Fetch(x => x.Author).Eager
				.Fetch(x => x.Blog).Eager
				.JoinQueryOver(x => x.SearchRequests)
				.Where(x => x.Id == context.SearchRequestId)
				.TransformUsing(Transformers.DistinctRootEntity)
                                .Skip(context.PageIndex*pageSize)
				.Take(pageSize);

Session.CreateMultiCriteria()
				.Add(queryOver.UnderlyingCriteria)
				.Add(queryOver.ToRowCountQuery().UnderlyingCriteria)
				.List();

I've found workaround using JoinAlias

-- 
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-2527) AbstractBatcher reuses disposed IDbCommands which causes an ArgumentOutOfRangeException with OracleDataClientDriver

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

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

cremor commented on NH-2527:
----------------------------

Sorry for the last comment, that was wrong. It doesn't work for all drivers since it subclasses the SQLite20Driver, but you should see the bug now with SQLite.

> AbstractBatcher reuses disposed IDbCommands which causes an ArgumentOutOfRangeException with OracleDataClientDriver
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: NH-2527
>                 URL: http://216.121.112.228/browse/NH-2527
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.0.0.GA
>            Reporter: cremor
>            Priority: Critical
>         Attachments: NH2527 Additional Test.zip, NH2527 Test.zip
>
>
> The attached test shows that the AbstractBatcher reuses already disposed IDbCommands in some cases (in my case, when an OneToMany entry is inserted and updated in the same commit). This seems to be no problem with some (most?) drivers (I tested SQLite20Driver and OracleClientDriver, both had no problems) but causes an ArgumentOutOfRangeException with the OracleDataClientDriver because the Parameters collection is empty.
> The dispose is called from AbstractBatcher.CloseCommand() which is called from OneToManyPersister.DoUpdateRows().
> AbstractBatcher.CloseCommand() checks if 'lastQuery' is the just disposed command and if yes clears it, but doesn't check 'batchCommand'. (Possible fix by calling InvalidateBatchCommand() if batchCommand == cmd.)
> Seems like a similar problem was already fixed for Firebird because the method AbstractBatcher.PrepareBatchCommand() checks for an empty CommandText and the comment says that it's unknown why it's empty sometimes. (Other possible fix by comparing batchCommand.Parameters.Count and parameterTypes.Length.)
> I don't know which of the two fixes would be better (or if there is an even better fix), therefore I didn't create a patch.
> Please note that even with one of the two fixes, the test still fails (with an StaleStateException) if you don't set adonet.batch_size to 0. I don't know why it doesn't work with batching, but this seems like a different bug.

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