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

[nhibernate-issues] [NHJIRA] Updated: (NH-2551) Bad code practice. Function SessionFactoryImpl.GetImplementors: if type not found - value from ReflectHelper.ClassForFullName returns through TypeLoadException.

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

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

Fabio Maulo updated NH-2551:
----------------------------

    Issue Type: Improvement  (was: Bug)

> Bad code practice. Function SessionFactoryImpl.GetImplementors: if type not found - value from ReflectHelper.ClassForFullName returns through TypeLoadException.
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: NH-2551
>                 URL: http://216.121.112.228/browse/NH-2551
>             Project:  NHibernate
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 3.0.0.GA
>            Reporter: Michael F.
>            Priority: Major
>
> Function NHibernate.DLL!NHibernate.Util.ReflectHelper.ClassForFullName(string classFullName) Line 222
> NHibernate.DLL!NHibernate.Impl.SessionFactoryImpl.GetImplementors(string className) Line 616
> to reproduce in VS2010
> 1. VS2010: set checkbox in menu Debug->Exceptions->Common language runtime exceptions->Thrown
> 2. try run standard test from a solution in debug mode:
> NHibernate.Test.Linq.ByMethod.AnyTests.AnySublist()
> 3. System.TypeLoadException will be thrown.

-- 
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-2553) Nhibernate fails to delete entity on MySql

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

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

Fabio Maulo closed NH-2553.
---------------------------

    Resolution: Cannot Reproduce

> Nhibernate fails to delete entity on MySql
> ------------------------------------------
>
>                 Key: NH-2553
>                 URL: http://216.121.112.228/browse/NH-2553
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.0.0.GA
>            Reporter: Søren Munk
>            Priority: Minor
>         Attachments: test+hbm.7z
>
>
> We get this error while committing the nh transaction. (If we dont use the transaction, we still get the error)
> System.IndexOutOfRangeException: Parameter index is out of range.
>    at MySql.Data.MySqlClient.MySqlParameterCollection.CheckIndex(Int32 index)
>    at MySql.Data.MySqlClient.MySqlParameterCollection.GetParameter(Int32 index)
>    at System.Data.Common.DbParameterCollection.System.Collections.IList.get_Item(Int32 index)
>    at NHibernate.Type.Int32Type.Set(IDbCommand rs, Object value, Int32 index)
>    at NHibernate.Type.NullableType.NullSafeSet(IDbCommand cmd, Object value, Int32 index)
>    at NHibernate.Type.NullableType.NullSafeSet(IDbCommand st, Object value, Int32 index, ISessionImplementor session)
>    at NHibernate.Persister.Entity.AbstractEntityPersister.Dehydrate(Object id, Object[] fields, Object rowId, Boolean[] includeProperty, Boolean[][] includeColumns, Int32 table, IDbCommand statement, ISessionImplementor session, Int32 index)
>    at NHibernate.Persister.Entity.AbstractEntityPersister.Update(Object id, Object[] fields, Object[] oldFields, Object rowId, Boolean[] includeProperty, Int32 j, Object oldVersion, Object obj, SqlCommandInfo sql, ISessionImplementor session)
>    at NHibernate.Persister.Entity.AbstractEntityPersister.UpdateOrInsert(Object id, Object[] fields, Object[] oldFields, Object rowId, Boolean[] includeProperty, Int32 j, Object oldVersion, Object obj, SqlCommandInfo sql, ISessionImplementor session)
>    at NHibernate.Persister.Entity.AbstractEntityPersister.Update(Object id, Object[] fields, Int32[] dirtyFields, Boolean hasDirtyCollection, Object[] oldFields, Object oldVersion, Object obj, Object rowId, ISessionImplementor session)
>    at NHibernate.Action.EntityUpdateAction.Execute()
>    at NHibernate.Engine.ActionQueue.Execute(IExecutable executable)
>    at NHibernate.Engine.ActionQueue.ExecuteActions(IList list)
>    at NHibernate.Engine.ActionQueue.ExecuteActions()
>    at NHibernate.Event.Default.AbstractFlushingEventListener.PerformExecutions(IEventSource session)
>    at NHibernate.Event.Default.DefaultFlushEventListener.OnFlush(FlushEvent event)
>    at NHibernate.Impl.SessionImpl.Flush()
> ...
> Our mapping is like this:
> <?xml version="1.0" encoding="utf-8" ?>
> <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" assembly="Model" namespace="Model">
>   <class name="ServerBillingMapping" table="rel_server_billing" lazy="true">
>     <id name="Id" column="rel_server_billing_id">
>       <generator class="native" />
>     </id>
>     <many-to-one name="Server" column="server_id" lazy="proxy" cascade="none" />
>     <many-to-one name="ServerType" column="servertype_id" lazy="proxy" cascade="none" />
>     <many-to-one name="Billing" column="billing_id" lazy="proxy" cascade="none" />
>   </class>
> </hibernate-mapping>
> <?xml version="1.0" encoding="utf-8" ?>
> <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" assembly="Model" namespace="Model">
>   <class name="Billing" table="billing" lazy="false">
>     <cache usage="read-write"/>
>     <id name="Id" column="billing_id">
>       <generator class="native" />
>     </id>
>     <set name="ServerMappings" lazy="true" table="rel_server_billing" cascade="all-delete-orphan">
>       <key column="billing_id" />
>       <one-to-many class="ServerBillingMapping" not-found="ignore" />
>     </set>
>   </class>
> </hibernate-mapping>
> Code:
> var billing = repo.FindBilling(Id);
> var mapping = billing.ServerMappings.Where(bla bla).FirstOrDefault();
> repo.Delete(mapping);
> billing.ServerMappings.Remove(mapping);
> repo.Save(billing);
> repo.CommitTransaction(); <-- calls flush, and fails.
> We also get an error "Method not supported". If ServerBillingMapping has mappings with lazy="no-proxy". And accessing the object through the reverse mapping. Eg. Billing.ServerMappings.FirstOrDefault();
> Method not supported.
>    at NHibernate.Proxy.AbstractProxyFactory.GetFieldInterceptionProxy() in d:\CSharp\NH\nhibernate\src\NHibernate\Proxy\AbstractProxyFactory.cs:line 49

-- 
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-2553) Nhibernate fails to delete entity on MySql

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

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

Fabio Maulo commented on NH-2553:
---------------------------------

With dirty data the flush may hit db since the sate of the entity in memory is different to the state uploaded (for example a null was found in DB and the property is Int32).

> Nhibernate fails to delete entity on MySql
> ------------------------------------------
>
>                 Key: NH-2553
>                 URL: http://216.121.112.228/browse/NH-2553
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.0.0.GA
>            Reporter: Søren Munk
>            Priority: Minor
>         Attachments: test+hbm.7z
>
>
> We get this error while committing the nh transaction. (If we dont use the transaction, we still get the error)
> System.IndexOutOfRangeException: Parameter index is out of range.
>    at MySql.Data.MySqlClient.MySqlParameterCollection.CheckIndex(Int32 index)
>    at MySql.Data.MySqlClient.MySqlParameterCollection.GetParameter(Int32 index)
>    at System.Data.Common.DbParameterCollection.System.Collections.IList.get_Item(Int32 index)
>    at NHibernate.Type.Int32Type.Set(IDbCommand rs, Object value, Int32 index)
>    at NHibernate.Type.NullableType.NullSafeSet(IDbCommand cmd, Object value, Int32 index)
>    at NHibernate.Type.NullableType.NullSafeSet(IDbCommand st, Object value, Int32 index, ISessionImplementor session)
>    at NHibernate.Persister.Entity.AbstractEntityPersister.Dehydrate(Object id, Object[] fields, Object rowId, Boolean[] includeProperty, Boolean[][] includeColumns, Int32 table, IDbCommand statement, ISessionImplementor session, Int32 index)
>    at NHibernate.Persister.Entity.AbstractEntityPersister.Update(Object id, Object[] fields, Object[] oldFields, Object rowId, Boolean[] includeProperty, Int32 j, Object oldVersion, Object obj, SqlCommandInfo sql, ISessionImplementor session)
>    at NHibernate.Persister.Entity.AbstractEntityPersister.UpdateOrInsert(Object id, Object[] fields, Object[] oldFields, Object rowId, Boolean[] includeProperty, Int32 j, Object oldVersion, Object obj, SqlCommandInfo sql, ISessionImplementor session)
>    at NHibernate.Persister.Entity.AbstractEntityPersister.Update(Object id, Object[] fields, Int32[] dirtyFields, Boolean hasDirtyCollection, Object[] oldFields, Object oldVersion, Object obj, Object rowId, ISessionImplementor session)
>    at NHibernate.Action.EntityUpdateAction.Execute()
>    at NHibernate.Engine.ActionQueue.Execute(IExecutable executable)
>    at NHibernate.Engine.ActionQueue.ExecuteActions(IList list)
>    at NHibernate.Engine.ActionQueue.ExecuteActions()
>    at NHibernate.Event.Default.AbstractFlushingEventListener.PerformExecutions(IEventSource session)
>    at NHibernate.Event.Default.DefaultFlushEventListener.OnFlush(FlushEvent event)
>    at NHibernate.Impl.SessionImpl.Flush()
> ...
> Our mapping is like this:
> <?xml version="1.0" encoding="utf-8" ?>
> <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" assembly="Model" namespace="Model">
>   <class name="ServerBillingMapping" table="rel_server_billing" lazy="true">
>     <id name="Id" column="rel_server_billing_id">
>       <generator class="native" />
>     </id>
>     <many-to-one name="Server" column="server_id" lazy="proxy" cascade="none" />
>     <many-to-one name="ServerType" column="servertype_id" lazy="proxy" cascade="none" />
>     <many-to-one name="Billing" column="billing_id" lazy="proxy" cascade="none" />
>   </class>
> </hibernate-mapping>
> <?xml version="1.0" encoding="utf-8" ?>
> <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" assembly="Model" namespace="Model">
>   <class name="Billing" table="billing" lazy="false">
>     <cache usage="read-write"/>
>     <id name="Id" column="billing_id">
>       <generator class="native" />
>     </id>
>     <set name="ServerMappings" lazy="true" table="rel_server_billing" cascade="all-delete-orphan">
>       <key column="billing_id" />
>       <one-to-many class="ServerBillingMapping" not-found="ignore" />
>     </set>
>   </class>
> </hibernate-mapping>
> Code:
> var billing = repo.FindBilling(Id);
> var mapping = billing.ServerMappings.Where(bla bla).FirstOrDefault();
> repo.Delete(mapping);
> billing.ServerMappings.Remove(mapping);
> repo.Save(billing);
> repo.CommitTransaction(); <-- calls flush, and fails.
> We also get an error "Method not supported". If ServerBillingMapping has mappings with lazy="no-proxy". And accessing the object through the reverse mapping. Eg. Billing.ServerMappings.FirstOrDefault();
> Method not supported.
>    at NHibernate.Proxy.AbstractProxyFactory.GetFieldInterceptionProxy() in d:\CSharp\NH\nhibernate\src\NHibernate\Proxy\AbstractProxyFactory.cs:line 49

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

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

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

Fabio Maulo closed NH-2659.
---------------------------

    Resolution: Obsolete

The dialect already have the function registration
public MsSqlCe40Dialect()
{
RegisterFunction("concat", new VarArgsSQLFunction(NHibernateUtil.String, "(", "+", ")"));
}


> 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.0.0.GA, 3.1.0
>            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] Resolved: (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 resolved NH-2661.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 3.2.0Alpha3

Implementing a new Drive for MsSQL2008

> 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
>             Fix For: 3.2.0Alpha3
>
>         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-2672) Upgrade Npgsql lib file to next release after 2.0.11.91.

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

Upgrade Npgsql lib file to next release after 2.0.11.91.
--------------------------------------------------------

                 Key: NH-2672
                 URL: http://216.121.112.228/browse/NH-2672
             Project:  NHibernate
          Issue Type: Task
          Components: Tests
    Affects Versions: 3.2.0Alpha2
            Reporter: Patrick Earl
            Assignee: Patrick Earl




-- 
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-2671) Fetch cannot be last statement

[michael s (JIRA) <nh...@gm...>]

Fetch cannot be last statement
------------------------------

                 Key: NH-2671
                 URL: http://216.121.112.228/browse/NH-2671
             Project:  NHibernate
          Issue Type: Bug
          Components: Linq Provider
    Affects Versions: 3.1.0
            Reporter: michael s
            Priority: Major


I am using WCF data services in conjuntion with Linq and received the exception whenever I try to use fetch to support the OData expand protocol.

Typical query:

from u in Products.Expand("Categories")
select u

Service Impl:

        public IQueryable<Product> Products
        {
            get
            {
                return _session.Query<Product>().Fetch(c => c.Categories);
            }
        }

This issue was reported fixed. The alternative to append ToList and AsQueryable is not appropriate as it will lead to filtering in memory as opposed to the database.




2011-04-24 21:24:07,353 [7] ERROR      - System.Data.Services.DataServiceException: Not Implemented ---> System.NotSupportedException: Specified method is not s
upported.
   at NHibernate.Hql.Ast.ANTLR.PolymorphicQuerySourceDetector.GetClassName(IASTNode querySource)
   at NHibernate.Hql.Ast.ANTLR.PolymorphicQuerySourceDetector.Process(IASTNode tree)
   at NHibernate.Hql.Ast.ANTLR.AstPolymorphicProcessor.Process()
   at NHibernate.Hql.Ast.ANTLR.AstPolymorphicProcessor.Process(IASTNode ast, ISessionFactoryImplementor factory)
   at NHibernate.Hql.Ast.ANTLR.ASTQueryTranslatorFactory.CreateQueryTranslators(IASTNode ast, String queryIdentifier, String collectionRole, Boolean shallow, ID
ictionary`2 filters, ISessionFactoryImplementor factory)
   at NHibernate.Hql.Ast.ANTLR.ASTQueryTranslatorFactory.CreateQueryTranslators(String queryIdentifier, IQueryExpression queryExpression, String collectionRole,
 Boolean shallow, IDictionary`2 filters, ISessionFactoryImplementor factory)
   at NHibernate.Engine.Query.HQLExpressionQueryPlan.CreateTranslators(String expressionStr, IQueryExpression queryExpression, String collectionRole, Boolean sh
allow, IDictionary`2 enabledFilters, ISessionFactoryImplementor factory)
   at NHibernate.Engine.Query.HQLExpressionQueryPlan..ctor(String expressionStr, IQueryExpression queryExpression, String collectionRole, Boolean shallow, IDict
ionary`2 enabledFilters, ISessionFactoryImplementor factory)
   at NHibernate.Engine.Query.HQLExpressionQueryPlan..ctor(String expressionStr, IQueryExpression queryExpression, Boolean shallow, IDictionary`2 enabledFilters
, ISessionFactoryImplementor factory)
   at NHibernate.Engine.Query.QueryPlanCache.GetHQLQueryPlan(IQueryExpression queryExpression, Boolean shallow, IDictionary`2 enabledFilters)
   at NHibernate.Impl.AbstractSessionImpl.GetHQLQueryPlan(IQueryExpression queryExpression, Boolean shallow)
   at NHibernate.Impl.AbstractSessionImpl.CreateQuery(IQueryExpression queryExpression)
   at NHibernate.Linq.NhQueryProvider.PrepareQuery(Expression expression, IQuery& query, NhLinqExpression& nhQuery)
   at NHibernate.Linq.NhQueryProvider.Execute(Expression expression)
   at NHibernate.Linq.NhQueryProvider.Execute[TResult](Expression expression)
   at Remotion.Data.Linq.QueryableBase`1.GetEnumerator()
   at System.Data.Services.Providers.BasicExpandProvider.ExpandedQueryable`1.GetEnumerator()
   at System.Data.Services.WebUtil.GetRequestEnumerator(IEnumerable enumerable)
   --- End of inner exception stack trace ---
   at System.Data.Services.WebUtil.GetRequestEnumerator(IEnumerable enumerable)
   at System.Data.Services.DataService`1.SerializeResponseBody(RequestDescription description, IDataService dataService)
   at System.Data.Services.DataService`1.HandleRequest()

-- 
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-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 closed NH-2660.
---------------------------

    Resolution: Won't Fix

Don't worry for the "won't fix"... I'm on the workaround of the Ms bug.
I'll introduce two new NH's types.
- DateTimeToTimeSpanType 
- TimeSpanType (with a breaking change for the old one who will renamed to TimeSpanAsInte64Type)

> 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] Resolved: (NH-2569) IDGeneratorBinding seems broken when mixing schemas

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

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

Fabio Maulo resolved NH-2569.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 3.2.0Alpha3

> IDGeneratorBinding seems broken when mixing schemas
> ---------------------------------------------------
>
>                 Key: NH-2569
>                 URL: http://216.121.112.228/browse/NH-2569
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.0.0.GA
>            Reporter: Ciaran Jessup
>            Priority: Minor
>             Fix For: 3.2.0Alpha3
>
>         Attachments: OverWriteSchemaInIdGenerator.patch
>
>
> We seem to have run into an issue when using the NHibernate.Id.TableHiLoGenerator over a table in a db schema different to the schema that the containing table/class belongs to. 
> A mapping similar to:
> <hibernate-mapping  xmlns="urn:nhibernate-mapping-2.2" assembly="MyAssembly" namespace="MyNamespace">
>   <class name="MyAssembly.MyAwesomeRecord, MyAssembly" table="MyAwesomeRecords" schema="Foo">
>     <id name="Id" column="mar_id" type="Int64" unsaved-value="-1">
> 	<generator class="NHibernate.Id.TableHiLoGenerator">
> 	  <param name="table">hilosequences</param>
> 	  <param name="column">sequence_next_hi_value</param>
> 	  <param name="where">sequence_name='MyAwesomeRecord'</param>
> 	  <param name="max_lo">1</param>
> 	  <param name="schema">Bar</param>
> 	</generator>
>     </id>
>    </class>
> </hibernate-mapping>
>  (Note the two schemas, Foo on the enclosing class, and Bar on he IDGenerator's underlying table)
> If included in your hibernate mappings will cause hibernate to fail to start with an exception along the lines of :
> 2011-03-10 11:04:19,777 [9] ERROR NHibernate.Cfg.Configuration [(null)] <(null)> - Could not compile the mapping document: Numero.SmartAgent.Workflow.Maps.WorkItem.hbm.xml
> NHibernate.MappingException: Could not compile the mapping document: MyAssembly.MyAwesomeRecord.hbm.xml ---> System.ArgumentException: An item with the same key has already been added.
>    at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
>    at NHibernate.Cfg.XmlHbmBinding.IdGeneratorBinder.GetGeneratorProperties(HbmGenerator generatorMapping, String schema)
>    at NHibernate.Cfg.XmlHbmBinding.IdGeneratorBinder.BindGenerator(SimpleValue id, HbmGenerator generatorMapping)
>    at NHibernate.Cfg.XmlHbmBinding.ClassIdBinder.BindId(HbmId idSchema, PersistentClass rootClass, Table table)
>    at NHibernate.Cfg.XmlHbmBinding.RootClassBinder.Bind(HbmClass classSchema, IDictionary`2 inheritedMetas)
>    at NHibernate.Cfg.XmlHbmBinding.MappingRootBinder.AddEntitiesMappings(HbmMapping mappingSchema, IDictionary`2 inheritedMetas)
>    at NHibernate.Cfg.XmlHbmBinding.MappingRootBinder.Bind(HbmMapping mappingSchema)
>    at NHibernate.Cfg.Configuration.AddDeserializedMapping(HbmMapping mappingDocument, String documentFileName)
>    --- End of inner exception stack trace --
> I believe this is caused by the IdGeneratorBinder#GetGeneratorProperties preferentially using the schema of the containing table/class and then trying to add the id generator's configured schema to the underlying collection after the table one has already been added. 
> I've supplied a trivial patch that I believe 'fixes' it for me, but it is most likely not the correct fix that someone else would want :)

-- 
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-1642) one-to-many collection doesn't work if the child is mapped using table per class

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

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

Fabio Maulo resolved NH-1642.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 3.2.0Alpha3

Fixed fixing NH-1747

> one-to-many collection doesn't work if the child is mapped using table per class
> --------------------------------------------------------------------------------
>
>                 Key: NH-1642
>                 URL: http://216.121.112.228/browse/NH-1642
>             Project:  NHibernate
>          Issue Type: Sub-task
>          Components: Core
>    Affects Versions:  2.0.1.GA
>            Reporter: Kiran Gawde
>            Priority: Major
>             Fix For: 3.2.0Alpha3
>
>         Attachments: KGTest.rar
>
>
> In the attached example, I have parent object TrafficRuleSet. It contains list of TrafficRule. TrafficRule has a backpointer to TrafficRuleSet. Also, TrafficRule is subclassed from AbstractRule. These are represented with three different tables.
> Now, when you try to retrieve the TrafficRuleSet and associated TrafficRules, it generates following query:
> select * from Traffic_RuleSet where gr.ruleset_id = '3'
> select * from Generic_Rule gr inner join Traffic_Rule tr on gr.rule_id = tr.rule_id where gr.ruleset_id = '3'
> (Note: Above sqls are simplied for clarity.)
> The second sql above is wrong. It should have been:
> select * from Generic_Rule gr inner join Traffic_Rule tr on gr.rule_id = tr.rule_id where tr.ruleset_id = '3'

-- 
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-1747) Lazy load failure on items using <join> if FK for bag is in the secondary table

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

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

Fabio Maulo resolved NH-1747.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 3.2.0Alpha3

Applied the whole fix... we have to add an early check for column-name used to represent different relations (comments added to the code for possibly future issues)

> Lazy load failure on items using <join> if FK for bag is in the secondary table
> -------------------------------------------------------------------------------
>
>                 Key: NH-1747
>                 URL: http://216.121.112.228/browse/NH-1747
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.1.0.Alpha2
>            Reporter: Anne Epstein
>            Priority: Minor
>             Fix For: 3.2.0Alpha3
>
>         Attachments: NH1747.zip
>
>
> When an element is mapped using <join> that contains a many-to-one that has that many-to-one key in the secondary table, and that element is put in a bag and lazy-loaded, the lazy load fails because the resulting SQL looks for the key in the element's primary table, not the secondary table.
> I'm attaching a test-when I run this on a preexisting db, it gives a SQL error for a nonexisting column.  When a schema is generated from the mapping, it (incorrectly) has the many-to-one FK in both the primary and secondary element tables-it uses the correct one when traversing from the element, but uses the wrong one when traversing from bag to child elements.
> The core issue seems to be that NHibernate doesn't know (and there doesn't seem to be a way) to tell a bag that the key column is in a secondary table of a join, not the primary one.

-- 
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-2670) Stateless Session load no-lazy collection

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

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

Fabio Maulo resolved NH-2670.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 3.2.0Alpha3

> Stateless Session load no-lazy collection
> -----------------------------------------
>
>                 Key: NH-2670
>                 URL: http://216.121.112.228/browse/NH-2670
>             Project:  NHibernate
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Fabio Maulo
>            Assignee: Fabio Maulo
>            Priority: Minor
>             Fix For: 3.2.0Alpha3
>
>
> The stateless-session ignores collection setting it to null.
> When a collection is not lazy it can be loaded with its container no matter which is the strategy (join/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] Resolved: (NH-2669) Patch to prevent "NHibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions

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

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

Fabio Maulo resolved NH-2669.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 3.2.0Alpha3

> Patch to prevent "NHibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: NH-2669
>                 URL: http://216.121.112.228/browse/NH-2669
>             Project:  NHibernate
>          Issue Type: Patch
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Rory Plaire
>            Assignee: Fabio Maulo
>            Priority: Minor
>             Fix For: 3.2.0Alpha3
>
>         Attachments: NH-2669.patch
>
>
> This is a patch copied from Hibernate 3.6.3 and tracked here: https://issues.jboss.org/browse/JBPAPP-3737
> ==========
>  In a stateless session, queries load objects in a two-phase process: in the first phase, a temporary persistence context is populated with empty objects; in the second phase, the objects' member data is read from the database. If an object contains an association or a collection, the query performs a recursive call to the session's get() method. This clears the temporary persistence context.
> If the parent object contained any other associations to be read as part of the second phase, Hibernate threw an assertion because the associations cannot be found in the persistence context.
> This has been fixed by introducing a new method: <literal>org.hibernate.engine.PersistenceContext.isLoadFinished()</literal>. This method tells StatelessSession when to clean the temporary persistence context.
> ==========

-- 
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-2670) Stateless Session load no-lazy collection

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

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

Fabio Maulo reassigned NH-2670:
-------------------------------

    Assignee: Fabio Maulo

> Stateless Session load no-lazy collection
> -----------------------------------------
>
>                 Key: NH-2670
>                 URL: http://216.121.112.228/browse/NH-2670
>             Project:  NHibernate
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Fabio Maulo
>            Assignee: Fabio Maulo
>            Priority: Minor
>
> The stateless-session ignores collection setting it to null.
> When a collection is not lazy it can be loaded with its container no matter which is the strategy (join/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-2670) Stateless Session load no-lazy collection

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

Stateless Session load no-lazy collection
-----------------------------------------

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


The stateless-session ignores collection setting it to null.
When a collection is not lazy it can be loaded with its container no matter which is the strategy (join/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] Commented: (NH-2669) Patch to prevent "NHibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions

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

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

Fabio Maulo commented on NH-2669:
---------------------------------

The patch break StatelessWithRelationsFixture.ShouldWorkLoadingComplexEntities test

> Patch to prevent "NHibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: NH-2669
>                 URL: http://216.121.112.228/browse/NH-2669
>             Project:  NHibernate
>          Issue Type: Patch
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Rory Plaire
>            Assignee: Fabio Maulo
>            Priority: Minor
>         Attachments: NH-2669.patch
>
>
> This is a patch copied from Hibernate 3.6.3 and tracked here: https://issues.jboss.org/browse/JBPAPP-3737
> ==========
>  In a stateless session, queries load objects in a two-phase process: in the first phase, a temporary persistence context is populated with empty objects; in the second phase, the objects' member data is read from the database. If an object contains an association or a collection, the query performs a recursive call to the session's get() method. This clears the temporary persistence context.
> If the parent object contained any other associations to be read as part of the second phase, Hibernate threw an assertion because the associations cannot be found in the persistence context.
> This has been fixed by introducing a new method: <literal>org.hibernate.engine.PersistenceContext.isLoadFinished()</literal>. This method tells StatelessSession when to clean the temporary persistence context.
> ==========

-- 
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-2669) Patch to prevent "NHibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions

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

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

Fabio Maulo updated NH-2669:
----------------------------

    Summary: Patch to prevent "NHibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions  (was: Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions)

> Patch to prevent "NHibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: NH-2669
>                 URL: http://216.121.112.228/browse/NH-2669
>             Project:  NHibernate
>          Issue Type: Patch
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Rory Plaire
>            Assignee: Fabio Maulo
>            Priority: Minor
>         Attachments: NH-2669.patch
>
>
> This is a patch copied from Hibernate 3.6.3 and tracked here: https://issues.jboss.org/browse/JBPAPP-3737
> ==========
>  In a stateless session, queries load objects in a two-phase process: in the first phase, a temporary persistence context is populated with empty objects; in the second phase, the objects' member data is read from the database. If an object contains an association or a collection, the query performs a recursive call to the session's get() method. This clears the temporary persistence context.
> If the parent object contained any other associations to be read as part of the second phase, Hibernate threw an assertion because the associations cannot be found in the persistence context.
> This has been fixed by introducing a new method: <literal>org.hibernate.engine.PersistenceContext.isLoadFinished()</literal>. This method tells StatelessSession when to clean the temporary persistence context.
> ==========

-- 
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-2669) Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions

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

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

Fabio Maulo reassigned NH-2669:
-------------------------------

    Assignee: Fabio Maulo

> Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: NH-2669
>                 URL: http://216.121.112.228/browse/NH-2669
>             Project:  NHibernate
>          Issue Type: Patch
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Rory Plaire
>            Assignee: Fabio Maulo
>            Priority: Minor
>         Attachments: NH-2669.patch
>
>
> This is a patch copied from Hibernate 3.6.3 and tracked here: https://issues.jboss.org/browse/JBPAPP-3737
> ==========
>  In a stateless session, queries load objects in a two-phase process: in the first phase, a temporary persistence context is populated with empty objects; in the second phase, the objects' member data is read from the database. If an object contains an association or a collection, the query performs a recursive call to the session's get() method. This clears the temporary persistence context.
> If the parent object contained any other associations to be read as part of the second phase, Hibernate threw an assertion because the associations cannot be found in the persistence context.
> This has been fixed by introducing a new method: <literal>org.hibernate.engine.PersistenceContext.isLoadFinished()</literal>. This method tells StatelessSession when to clean the temporary persistence context.
> ==========

-- 
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-2669) Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions

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

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

Fabio Maulo updated NH-2669:
----------------------------

    Affects Version/s:     (was: 3.2.0Alpha3)
                           (was: 3.2.0Alpha2)
                           (was: 3.2.0Alpha1)
                           (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)
                           (was:  2.0.1.GA)
                           (was: 1.2.1)

> Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: NH-2669
>                 URL: http://216.121.112.228/browse/NH-2669
>             Project:  NHibernate
>          Issue Type: Patch
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Rory Plaire
>            Priority: Minor
>         Attachments: NH-2669.patch
>
>
> This is a patch copied from Hibernate 3.6.3 and tracked here: https://issues.jboss.org/browse/JBPAPP-3737
> ==========
>  In a stateless session, queries load objects in a two-phase process: in the first phase, a temporary persistence context is populated with empty objects; in the second phase, the objects' member data is read from the database. If an object contains an association or a collection, the query performs a recursive call to the session's get() method. This clears the temporary persistence context.
> If the parent object contained any other associations to be read as part of the second phase, Hibernate threw an assertion because the associations cannot be found in the persistence context.
> This has been fixed by introducing a new method: <literal>org.hibernate.engine.PersistenceContext.isLoadFinished()</literal>. This method tells StatelessSession when to clean the temporary persistence context.
> ==========

-- 
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-2669) Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions

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

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

Rory Plaire updated NH-2669:
----------------------------

    Attachment: NH-2669.patch

> Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: NH-2669
>                 URL: http://216.121.112.228/browse/NH-2669
>             Project:  NHibernate
>          Issue Type: Patch
>          Components: Core
>    Affects Versions: 1.2.1,  2.0.1.GA, 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, 3.2.0Alpha1, 3.2.0Alpha2, 3.2.0Alpha3
>            Reporter: Rory Plaire
>            Priority: Minor
>         Attachments: NH-2669.patch
>
>
> This is a patch copied from Hibernate 3.6.3 and tracked here: https://issues.jboss.org/browse/JBPAPP-3737
> ==========
>  In a stateless session, queries load objects in a two-phase process: in the first phase, a temporary persistence context is populated with empty objects; in the second phase, the objects' member data is read from the database. If an object contains an association or a collection, the query performs a recursive call to the session's get() method. This clears the temporary persistence context.
> If the parent object contained any other associations to be read as part of the second phase, Hibernate threw an assertion because the associations cannot be found in the persistence context.
> This has been fixed by introducing a new method: <literal>org.hibernate.engine.PersistenceContext.isLoadFinished()</literal>. This method tells StatelessSession when to clean the temporary persistence context.
> ==========

-- 
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-2669) Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions

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

Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions
-----------------------------------------------------------------------------------------------------------------------------------

                 Key: NH-2669
                 URL: http://216.121.112.228/browse/NH-2669
             Project:  NHibernate
          Issue Type: Patch
          Components: Core
    Affects Versions: 3.2.0Alpha2, 3.2.0Alpha1, 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,  2.0.1.GA, 1.2.1, 3.2.0Alpha3
            Reporter: Rory Plaire
            Priority: Minor
         Attachments: NH-2669.patch

This is a patch copied from Hibernate 3.6.3 and tracked here: https://issues.jboss.org/browse/JBPAPP-3737

==========
 In a stateless session, queries load objects in a two-phase process: in the first phase, a temporary persistence context is populated with empty objects; in the second phase, the objects' member data is read from the database. If an object contains an association or a collection, the query performs a recursive call to the session's get() method. This clears the temporary persistence context.

If the parent object contained any other associations to be read as part of the second phase, Hibernate threw an assertion because the associations cannot be found in the persistence context.

This has been fixed by introducing a new method: <literal>org.hibernate.engine.PersistenceContext.isLoadFinished()</literal>. This method tells StatelessSession when to clean the temporary persistence context.
==========


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

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

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

Fabio Maulo commented on NH-2661:
---------------------------------

Sorry I mean "we can't change".
To work with pure Time we have TimeAsTimeSpan.
I'll try to find a solution without break everything for those ppl using 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-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:comment-tabpanel&focusedCommentId=20950#action_20950 ] 

Fabio Maulo commented on NH-2661:
---------------------------------

Neal, you can't change the TimeType that way because not all RDBMS may accepts a TimeSpan in the value of a parameter of DbType.Time.

In practice what you are looking for is something that use a DateTime in the domain and a TimeSpan for the DB.

> 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] Closed: (NH-2668) REOPEN: Version properties which are NULL in the database cause exceptions during a delete or update

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

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

Fabio Maulo closed NH-2668.
---------------------------

    Resolution: Won't Fix

> REOPEN: Version properties which are NULL in the database cause exceptions during a delete or update
> ----------------------------------------------------------------------------------------------------
>
>                 Key: NH-2668
>                 URL: http://216.121.112.228/browse/NH-2668
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 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, 3.2.0Alpha1, 3.2.0Alpha2
>            Reporter: Mike Pontillo
>            Priority: Major
>         Attachments: NH2667-fix.patch, NH2667-TestCases.patch
>
>
> Reopening NH-2667 as a new defect since it appears that I cannot reopen it myself. NH-2667 was closed before I could even attach the test case. Please don't close this yet; let the test case speak for itself. 
> I tried using unsaved-value and it did not work. There are, in fact, bugs here.

-- 
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-2668) REOPEN: Version properties which are NULL in the database cause exceptions during a delete or update

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

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

Fabio Maulo commented on NH-2668:
---------------------------------

In fact in your test you have:
                // Unsure if there is a cross-platform way to do this.
                // (Need to drop the "not null" constraint.)
                ExecuteSql(session, "alter table Info alter column Version INT");

                // ... and need to bypass NHibernate to insert the following rows, in order
                // to simulate rows in a legacy database that were "already there".
                ExecuteSql(session, "insert into Info values (1, 'Positive version')");
                ExecuteSql(session, "insert into Info values (0, 'Zero version')");
                ExecuteSql(session, "insert into Info values (null, 'NULL version')");
                ExecuteSql(session, "insert into Info values (-1, 'Negative version')");

> REOPEN: Version properties which are NULL in the database cause exceptions during a delete or update
> ----------------------------------------------------------------------------------------------------
>
>                 Key: NH-2668
>                 URL: http://216.121.112.228/browse/NH-2668
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 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, 3.2.0Alpha1, 3.2.0Alpha2
>            Reporter: Mike Pontillo
>            Priority: Major
>         Attachments: NH2667-fix.patch, NH2667-TestCases.patch
>
>
> Reopening NH-2667 as a new defect since it appears that I cannot reopen it myself. NH-2667 was closed before I could even attach the test case. Please don't close this yet; let the test case speak for itself. 
> I tried using unsaved-value and it did not work. There are, in fact, bugs here.

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