Menu
▾
▴
nhibernate-issues — Updates to JIRA issues are sent to this list
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(110) |
Nov
(296) |
Dec
(107) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(212) |
Feb
(263) |
Mar
(161) |
Apr
(183) |
May
(183) |
Jun
(75) |
Jul
(106) |
Aug
(88) |
Sep
(227) |
Oct
(143) |
Nov
(154) |
Dec
(53) |
| 2008 |
Jan
(77) |
Feb
|
Mar
|
Apr
(6) |
May
(103) |
Jun
(296) |
Jul
(54) |
Aug
|
Sep
(379) |
Oct
(283) |
Nov
(224) |
Dec
(214) |
| 2009 |
Jan
(129) |
Feb
(257) |
Mar
(136) |
Apr
(12) |
May
(329) |
Jun
(434) |
Jul
(375) |
Aug
(171) |
Sep
|
Oct
|
Nov
|
Dec
(54) |
| 2010 |
Jan
(198) |
Feb
(76) |
Mar
(3) |
Apr
(1) |
May
|
Jun
(62) |
Jul
(210) |
Aug
(447) |
Sep
(330) |
Oct
(257) |
Nov
(133) |
Dec
(453) |
| 2011 |
Jan
(240) |
Feb
(128) |
Mar
(442) |
Apr
(320) |
May
(428) |
Jun
(141) |
Jul
(13) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: NHibernate J. <mik...@us...> - 2006-11-17 17:58:31
|
[ http://jira.nhibernate.org/browse/NH-816?page=all ] Fabio Maulo updated NH-816: --------------------------- Attachment: CriteriaWithClassProperties.patch Patch for the issue. All NHb old test passed. > Criteria using class with discriminator > --------------------------------------- > > Key: NH-816 > URL: http://jira.nhibernate.org/browse/NH-816 > Project: NHibernate > Type: Bug > Components: Core > Versions: 1.2.0.Beta2 > Reporter: Fabio Maulo > Priority: Minor > Attachments: CriteriaWithClassProperties.patch > > session.CreateCriteria(typeof(MaterialUnit),"mu") > .CreateAlias("mu.Material", "ma") > .Add(Expression.Property.ForName("ma.class").Eq(typeof(MaterialUnitable))) > .List(); > The problem is in CriteriaQueryTranslator.GetTypedValue because the method use the DiscriminatorSQLValue istead DicriminatorValue. > I'm working on it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-17 16:49:27
|
Criteria using class with discriminator
---------------------------------------
Key: NH-816
URL: http://jira.nhibernate.org/browse/NH-816
Project: NHibernate
Type: Bug
Components: Core
Versions: 1.2.0.Beta2
Reporter: Fabio Maulo
Priority: Minor
session.CreateCriteria(typeof(MaterialUnit),"mu")
.CreateAlias("mu.Material", "ma")
.Add(Expression.Property.ForName("ma.class").Eq(typeof(MaterialUnitable)))
.List();
The problem is in CriteriaQueryTranslator.GetTypedValue because the method use the DiscriminatorSQLValue istead DicriminatorValue.
I'm working on it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.nhibernate.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: NHibernate J. <mik...@us...> - 2006-11-17 16:36:28
|
[ http://jira.nhibernate.org/browse/NH-428?page=comments#action_14424 ] Sergey Koshcheyev commented on NH-428: -------------------------------------- This means I have definitely decided that it won't be fixed in 1.2.0.CR1. > Support Multiple Collections join fetch > --------------------------------------- > > Key: NH-428 > URL: http://jira.nhibernate.org/browse/NH-428 > Project: NHibernate > Type: New Feature > Components: Core > Versions: 1.0 > Reporter: Phoebus Orient > Fix For: LATER > > There is no issue tracked in this system about this topic. I'd like to add this one. > Hope supporting multiple collections can be ported from hibernate soon. The related topics about it from forum are here: > http://nhibernate.sourceforge.net/forum/viewtopic.php?t=952 > http://nhibernate.sourceforge.net/forum/viewtopic.php?t=697 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-17 16:00:37
|
[ http://jira.nhibernate.org/browse/NH-815?page=all ] Sergey Koshcheyev updated NH-815: --------------------------------- Fix Version: 1.2.0.CR1 > SQLQueryImpl fails to bind parameter lists > ------------------------------------------ > > Key: NH-815 > URL: http://jira.nhibernate.org/browse/NH-815 > Project: NHibernate > Type: Bug > Components: Core > Versions: 1.2.0.Beta2 > Reporter: Peter Jaffe > Fix For: 1.2.0.CR1 > > The SQLQueryImpl class does not bind parameter lists properly. This is very easy to reproduce with a simple SQLQuery that has a single named parameter in the WHERE clause (e.g. "where id in (:idList)") and then use the ISQLQuery.SetParameterList("idList", someCollection). This works with an IQuery but fails with an ISQLQuery. > I debugged through the source of the 1.2.0 Beta2 and the fix appears very straightforward. See the code snippet below that indicates where the method argument "parameters" should probably be used instead of the class's NamedParams property. > public class SqlQueryImpl : AbstractQueryImpl, ISQLQuery > { > ... > public NativeSQLQuerySpecification GenerateQuerySpecification(IDictionary parameters) > { > return new NativeSQLQuerySpecification( > BindParameterLists(NamedParams), <-- ** Probably should have been "parameters" ** > GetQueryReturns(), > querySpaces); > } > ... > } > I'm using the MS SQL Server ADO.NET provider and running under .NET 2.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-17 15:56:29
|
[ http://jira.nhibernate.org/browse/NH-428?page=comments#action_14423 ] Phoebus Orient commented on NH-428: ----------------------------------- Still no ETA so far? I noticed the Fix Version was changed to "LATER", what does this mean? > Support Multiple Collections join fetch > --------------------------------------- > > Key: NH-428 > URL: http://jira.nhibernate.org/browse/NH-428 > Project: NHibernate > Type: New Feature > Components: Core > Versions: 1.0 > Reporter: Phoebus Orient > Fix For: LATER > > There is no issue tracked in this system about this topic. I'd like to add this one. > Hope supporting multiple collections can be ported from hibernate soon. The related topics about it from forum are here: > http://nhibernate.sourceforge.net/forum/viewtopic.php?t=952 > http://nhibernate.sourceforge.net/forum/viewtopic.php?t=697 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-17 15:46:30
|
SQLQueryImpl fails to bind parameter lists
------------------------------------------
Key: NH-815
URL: http://jira.nhibernate.org/browse/NH-815
Project: NHibernate
Type: Bug
Components: Core
Versions: 1.2.0.Beta2
Reporter: Peter Jaffe
The SQLQueryImpl class does not bind parameter lists properly. This is very easy to reproduce with a simple SQLQuery that has a single named parameter in the WHERE clause (e.g. "where id in (:idList)") and then use the ISQLQuery.SetParameterList("idList", someCollection). This works with an IQuery but fails with an ISQLQuery.
I debugged through the source of the 1.2.0 Beta2 and the fix appears very straightforward. See the code snippet below that indicates where the method argument "parameters" should probably be used instead of the class's NamedParams property.
public class SqlQueryImpl : AbstractQueryImpl, ISQLQuery
{
...
public NativeSQLQuerySpecification GenerateQuerySpecification(IDictionary parameters)
{
return new NativeSQLQuerySpecification(
BindParameterLists(NamedParams), <-- ** Probably should have been "parameters" **
GetQueryReturns(),
querySpaces);
}
...
}
I'm using the MS SQL Server ADO.NET provider and running under .NET 2.0.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.nhibernate.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: NHibernate J. <mik...@us...> - 2006-11-17 06:57:29
|
[ http://jira.nhibernate.org/browse/NH-814?page=3Dcomments#action_1442= 2 ] =20 Ayende Rahien commented on NH-814: ---------------------------------- It there a reason you cannot use a nosetter access strategy? That would by pass your properties. > Resetting of properties after initial set violates constraints we want to= protect > -------------------------------------------------------------------------= -------- > > Key: NH-814 > URL: http://jira.nhibernate.org/browse/NH-814 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.0.2 > Reporter: Jim Showalter > Fix For: LATER > > We have properties on objects that are supposed to be set only once, when= first reading an object back from the database. Once in memory, they are n= ot supposed to be set again, and attempting to do so is supposed to throw a= n exception. Unfortunately, nhibernate's behavior appears to be less predic= table than we had thought. It assigns properties more than once. For exampl= e, when merging a disconnected object, it loads one from the database (thus= setting the properties), and then sets them again from the other object, t= hus violating the set-once rule. There are other cases similar to this. We = modified our rule to allow setting to null (or some other value indicating = not-yet-set) as many times as desired, then setting to some actual value, a= nd allowing setting to that same value as many times as desired. Setting to= a different value once set throws an exception. This seems to pacify nhibe= rnate, but we're not certain that it will work in all cases, and the behavi= or of nhibernate as far as resetting properties is concerned is undefined. = Our request is for nhibernate to be enhanced to have a notion of set-once, = which would be stated in the HBM file. This would make a property immutable= , with the sole setting of that property to be done on reading in from the = database. On save, a set-once property would be assumed to have already bee= n set--nhibernate would not set it itself when saving, only when reading. > This same request has been filed for hibernate as HHH-2245. --=20 This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-17 05:24:28
|
[ http://jira.nhibernate.org/browse/NH-813?page=comments#action_14421 ] Sergey Koshcheyev commented on NH-813: -------------------------------------- This would be great of course, but it's probably a separate issue. I haven't yet looked at what would be the correct way to fix this problem so I can't tell if entity-names would be the right solution. > CacheKey key is invalid - memcached fails to store objects. > ----------------------------------------------------------- > > Key: NH-813 > URL: http://jira.nhibernate.org/browse/NH-813 > Project: NHibernate > Type: Patch > Components: Core > Versions: 1.2.0.Beta2 > Reporter: Stuart Carnie > Fix For: 1.2.0.CR1 > Attachments: cachekey-fix.patch > > The CacheKey derives from IdentifierSpace, which is EntityMetaModel.RootTypeAssemblyQualifiedName. This name contains spaces, which causes an issue with MemCache, in the 'set' command. With the spaces in the key, an invalid command is sent to the memcached server. > I have provided a patch that exposes a new property on EntityMetaModel, RootName (to match the property name in Hibernate), which simply replaces the spaces with underscores '_'. Now memcached caching works fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-17 05:19:28
|
[ http://jira.nhibernate.org/browse/NH-813?page=comments#action_14420 ] Stuart Carnie commented on NH-813: ---------------------------------- I can port the functionality of Hibernate, if preferred. This allows the 'entity-name' attribute to be specified in the hbm.xml files. > CacheKey key is invalid - memcached fails to store objects. > ----------------------------------------------------------- > > Key: NH-813 > URL: http://jira.nhibernate.org/browse/NH-813 > Project: NHibernate > Type: Patch > Components: Core > Versions: 1.2.0.Beta2 > Reporter: Stuart Carnie > Fix For: 1.2.0.CR1 > Attachments: cachekey-fix.patch > > The CacheKey derives from IdentifierSpace, which is EntityMetaModel.RootTypeAssemblyQualifiedName. This name contains spaces, which causes an issue with MemCache, in the 'set' command. With the spaces in the key, an invalid command is sent to the memcached server. > I have provided a patch that exposes a new property on EntityMetaModel, RootName (to match the property name in Hibernate), which simply replaces the spaces with underscores '_'. Now memcached caching works fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-17 05:08:34
|
[ http://jira.nhibernate.org/browse/NH-814?page=3Dall ] Sergey Koshcheyev updated NH-814: --------------------------------- Fix Version: LATER Component: Core > Resetting of properties after initial set violates constraints we want to= protect > -------------------------------------------------------------------------= -------- > > Key: NH-814 > URL: http://jira.nhibernate.org/browse/NH-814 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.0.2 > Reporter: Jim Showalter > Fix For: LATER > > We have properties on objects that are supposed to be set only once, when= first reading an object back from the database. Once in memory, they are n= ot supposed to be set again, and attempting to do so is supposed to throw a= n exception. Unfortunately, nhibernate's behavior appears to be less predic= table than we had thought. It assigns properties more than once. For exampl= e, when merging a disconnected object, it loads one from the database (thus= setting the properties), and then sets them again from the other object, t= hus violating the set-once rule. There are other cases similar to this. We = modified our rule to allow setting to null (or some other value indicating = not-yet-set) as many times as desired, then setting to some actual value, a= nd allowing setting to that same value as many times as desired. Setting to= a different value once set throws an exception. This seems to pacify nhibe= rnate, but we're not certain that it will work in all cases, and the behavi= or of nhibernate as far as resetting properties is concerned is undefined. = Our request is for nhibernate to be enhanced to have a notion of set-once, = which would be stated in the HBM file. This would make a property immutable= , with the sole setting of that property to be done on reading in from the = database. On save, a set-once property would be assumed to have already bee= n set--nhibernate would not set it itself when saving, only when reading. > This same request has been filed for hibernate as HHH-2245. --=20 This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-17 05:08:29
|
[ http://jira.nhibernate.org/browse/NH-693?page=all ] Sergey Koshcheyev updated NH-693: --------------------------------- Fix Version: 1.2.0.CR1 Version: 1.2.0.Beta2 > Better Error Msg > ---------------- > > Key: NH-693 > URL: http://jira.nhibernate.org/browse/NH-693 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.2.0.Beta2 > Reporter: Dru Sellers > Priority: Minor > Fix For: 1.2.0.CR1 > > Can we have better error msg for this error? > "NHibernate.MappingException: Index was outside the bounds of the array. ---> System.IndexOutOfRangeException: Index was outside the bounds of the array. > at NHibernate.Mapping.Table.set_Name(String value) > at NHibernate.Cfg.Mappings.AddTable(String schema, String name) > at NHibernate.Cfg.Binder.BindRootClass(XmlNode node, RootClass model, Mappings mappings) > at NHibernate.Cfg.Binder.BindRoot(XmlDocument doc, Mappings model) > at NHibernate.Cfg.Configuration.AddValidatedDocument(XmlDocument doc) > at NHibernate.Cfg.Configuration.AddXmlReader(XmlTextReader hbmReader) > at NHibernate.Cfg.Configuration.AddInputStream(Stream xmlInputStream) > --- End of inner exception stack trace --- > at NHibernate.Cfg.Configuration.AddInputStream(Stream xmlInputStream) > at NHibernate.Cfg.Configuration.AddAssembly(Assembly assembly, Boolean skipOrdering) > at NHibernate.Cfg.Configuration.AddAssembly(Assembly assembly) > at NHibernate.Cfg.Configuration.AddAssembly(String assemblyName) > I would be happy to code it up, but not sure where to best put the check? > NHibernate.Mapping.Table.set_Name (least amount of code repeat.) > or > NHibernate.Cfg.Mappings.AddTable(String schema, String name) best place to provide the most info possible. Actually this is a bad place too. > --Thoughts?-- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-17 05:06:32
|
[ http://jira.nhibernate.org/browse/NH-813?page=all ] Sergey Koshcheyev updated NH-813: --------------------------------- Fix Version: 1.2.0.CR1 > CacheKey key is invalid - memcached fails to store objects. > ----------------------------------------------------------- > > Key: NH-813 > URL: http://jira.nhibernate.org/browse/NH-813 > Project: NHibernate > Type: Patch > Components: Core > Versions: 1.2.0.Beta2 > Reporter: Stuart Carnie > Fix For: 1.2.0.CR1 > Attachments: cachekey-fix.patch > > The CacheKey derives from IdentifierSpace, which is EntityMetaModel.RootTypeAssemblyQualifiedName. This name contains spaces, which causes an issue with MemCache, in the 'set' command. With the spaces in the key, an invalid command is sent to the memcached server. > I have provided a patch that exposes a new property on EntityMetaModel, RootName (to match the property name in Hibernate), which simply replaces the spaces with underscores '_'. Now memcached caching works fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-16 21:22:34
|
Resetting of properties after initial set violates constraints we want to p=
rotect
---------------------------------------------------------------------------=
------
Key: NH-814
URL: http://jira.nhibernate.org/browse/NH-814
Project: NHibernate
Type: Improvement
Versions: 1.0.2 =20
Reporter: Jim Showalter
We have properties on objects that are supposed to be set only once, when f=
irst reading an object back from the database. Once in memory, they are not=
supposed to be set again, and attempting to do so is supposed to throw an =
exception. Unfortunately, nhibernate's behavior appears to be less predicta=
ble than we had thought. It assigns properties more than once. For example,=
when merging a disconnected object, it loads one from the database (thus s=
etting the properties), and then sets them again from the other object, thu=
s violating the set-once rule. There are other cases similar to this. We mo=
dified our rule to allow setting to null (or some other value indicating no=
t-yet-set) as many times as desired, then setting to some actual value, and=
allowing setting to that same value as many times as desired. Setting to a=
different value once set throws an exception. This seems to pacify nhibern=
ate, but we're not certain that it will work in all cases, and the behavior=
of nhibernate as far as resetting properties is concerned is undefined. Ou=
r request is for nhibernate to be enhanced to have a notion of set-once, wh=
ich would be stated in the HBM file. This would make a property immutable, =
with the sole setting of that property to be done on reading in from the da=
tabase. On save, a set-once property would be assumed to have already been =
set--nhibernate would not set it itself when saving, only when reading.
This same request has been filed for hibernate as HHH-2245.
--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.nhibernate.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: NHibernate J. <mik...@us...> - 2006-11-16 19:30:29
|
CacheKey key is invalid - memcached fails to store objects.
-----------------------------------------------------------
Key: NH-813
URL: http://jira.nhibernate.org/browse/NH-813
Project: NHibernate
Type: Patch
Components: Core
Versions: 1.2.0.Beta2
Reporter: Stuart Carnie
Attachments: cachekey-fix.patch
The CacheKey derives from IdentifierSpace, which is EntityMetaModel.RootTypeAssemblyQualifiedName. This name contains spaces, which causes an issue with MemCache, in the 'set' command. With the spaces in the key, an invalid command is sent to the memcached server.
I have provided a patch that exposes a new property on EntityMetaModel, RootName (to match the property name in Hibernate), which simply replaces the spaces with underscores '_'. Now memcached caching works fine.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.nhibernate.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: NHibernate J. <mik...@us...> - 2006-11-16 19:20:29
|
[ http://jira.nhibernate.org/browse/NH-812?page=all ] Sergey Koshcheyev updated NH-812: --------------------------------- Fix Version: 1.2.0.CR1 Version: 1.2.0.Beta2 > PostgreSQL - for update no wait > ------------------------------- > > Key: NH-812 > URL: http://jira.nhibernate.org/browse/NH-812 > Project: NHibernate > Type: Bug > Components: Data Providers > Versions: 1.2.0.Beta2 > Reporter: Bernhard Adelsmair > Priority: Trivial > Fix For: 1.2.0.CR1 > Attachments: PostgreSQL81Dialect.cs > > Hello!! > In the PostgreSQL Version 8.1 it is possible to Lock with Mode "FOR UPDATE NO WAIT". > But there was a mistake in the PostgreSQL81Dialect.cs file. There is a missing backspace before the "for". > yours sincerely > Bernhard Adelsmair > P.S.: > The file should look like: > using System; > namespace NHibernate.Dialect > { > /// <summary> > /// An SQL dialect for PostgreSQL 8.1 and above. > /// </summary> > /// <remarks> > /// PostgreSQL 8.1 supports <c>FOR UPDATE ... NOWAIT</c> syntax. > /// See <see cref="PostgreSQLDialect" /> for more information. > /// </remarks> > public class PostgreSQL81Dialect : PostgreSQLDialect > { > public override string ForUpdateNowaitString > { > get { return " for update nowait"; } > } > public override string GetForUpdateNowaitString( string aliases ) > { > return " for update of " + aliases + " nowait"; > } > } > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-16 19:15:43
|
PostgreSQL - for update no wait
-------------------------------
Key: NH-812
URL: http://jira.nhibernate.org/browse/NH-812
Project: NHibernate
Type: Bug
Components: Data Providers
Reporter: Bernhard Adelsmair
Priority: Trivial
Attachments: PostgreSQL81Dialect.cs
Hello!!
In the PostgreSQL Version 8.1 it is possible to Lock with Mode "FOR UPDATE NO WAIT".
But there was a mistake in the PostgreSQL81Dialect.cs file. There is a missing backspace before the "for".
yours sincerely
Bernhard Adelsmair
P.S.:
The file should look like:
using System;
namespace NHibernate.Dialect
{
/// <summary>
/// An SQL dialect for PostgreSQL 8.1 and above.
/// </summary>
/// <remarks>
/// PostgreSQL 8.1 supports <c>FOR UPDATE ... NOWAIT</c> syntax.
/// See <see cref="PostgreSQLDialect" /> for more information.
/// </remarks>
public class PostgreSQL81Dialect : PostgreSQLDialect
{
public override string ForUpdateNowaitString
{
get { return " for update nowait"; }
}
public override string GetForUpdateNowaitString( string aliases )
{
return " for update of " + aliases + " nowait";
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.nhibernate.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: NHibernate J. <mik...@us...> - 2006-11-16 11:55:29
|
[ http://jira.nhibernate.org/browse/NH-801?page=all ] Sergey Koshcheyev closed NH-801: -------------------------------- Resolution: Fixed > Upgrade NAnt libraries to 0.85 > ------------------------------ > > Key: NH-801 > URL: http://jira.nhibernate.org/browse/NH-801 > Project: NHibernate > Type: Task > Components: Toolset > Versions: 1.2.0.Beta1 > Reporter: Sergey Koshcheyev > Priority: Trivial > Fix For: 1.2.0.CR1 > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-16 10:49:30
|
[ http://jira.nhibernate.org/browse/NH-810?page=all ] Sergey Koshcheyev closed NH-810: -------------------------------- Resolution: Fixed > Prevent use of many-to-one association in Expression.Eq > ------------------------------------------------------- > > Key: NH-810 > URL: http://jira.nhibernate.org/browse/NH-810 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.2.0.Beta2 > Reporter: Sergiy Strelbitskyy > Priority: Minor > Fix For: 1.2.0.CR1 > Attachments: IssueDemo.RAR > > many-to-one mapping and Expression.Eq fails when trying to do Criteria.List() > Sample project to reproduce this error in attach. > Configuration: .NET2, MS SQL 2005 > See also: http://forum.hibernate.org/viewtopic.php?t=967213 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-15 21:16:24
|
[ http://jira.nhibernate.org/browse/NH-802?page=comments#action_14416 ] Ayende Rahien commented on NH-802: ---------------------------------- I don't see any value in using msbuild over nant. They are comparable in nearly any way. Major advantage for MsBuild is that it means automatic sync from VS to the build scripts (which are basically the same). The problem is that NH's build scripts are not trivial, and it would be a lot of work to port them, and I don't see a lot of benefit as a result. Mono does have xbuild, which is MsBuild for Linux. > Investigate possible use of MSBuild to build the project > -------------------------------------------------------- > > Key: NH-802 > URL: http://jira.nhibernate.org/browse/NH-802 > Project: NHibernate > Type: Task > Components: Toolset > Versions: 1.2.0.Beta1 > Reporter: Sergey Koshcheyev > Fix For: LATER > > Need to see whether MSBuild can handle everything that NAnt can, and maybe switch if so. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-15 20:26:30
|
[ http://jira.nhibernate.org/browse/NH-802?page=comments#action_14415 ] Dru Sellers commented on NH-802: -------------------------------- NAnt is nice because it is another open source project, and it works on Mono (Does MSBuild?) MSBuild is nice because if you have the .Net 2.0 installed you won't have to download and setup NAnt. What is it going to take to convert the build scripts to MSBuild from NAnt, I am sure it isn't trivial and if we aren't going to get any substantial benefits then I am for staying with NAnt. > Investigate possible use of MSBuild to build the project > -------------------------------------------------------- > > Key: NH-802 > URL: http://jira.nhibernate.org/browse/NH-802 > Project: NHibernate > Type: Task > Components: Toolset > Versions: 1.2.0.Beta1 > Reporter: Sergey Koshcheyev > Fix For: LATER > > Need to see whether MSBuild can handle everything that NAnt can, and maybe switch if so. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-15 17:31:38
|
[ http://jira.nhibernate.org/browse/NH-514?page=comments#action_14414 ] Luis Ferreira commented on NH-514: ---------------------------------- Hibernate filters should also, in my opinion, add their conditions to the "on" clause. > Allow expansion of the "on" clause in joins. > -------------------------------------------- > > Key: NH-514 > URL: http://jira.nhibernate.org/browse/NH-514 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.0 > Reporter: Dave McMullan > Priority: Critical > Fix For: LATER > > In english, I want a list of trades in a portfolio, whether tradeprices exist or not... but if they exist, they should be dated at least 7/1/2005. > In oracle, it looks like: > from trade t, tradeprice tp where t.portfolio=53 and tp.tradeid(+)=t.tradeid and tp.effdate(+) >= '1-Jul-2005' > In ansi, it looks like: > from trade t left outer join tradeprice tp on t.tradeid=tp.tradeid and tp.effdate >= '1-Jul-2005' where t.portfolio=53 > In HQL, the closest I can get is: > from trade t left join fetch t.tradeprices tp where t.portfolio=53 and tp.effdate >= '1-Jul-2005' > But that HQL generates this incorrect SQL: > from trade t left outer join tradeprice tp on t.tradeid=tp.tradeid where t.portfolio=53 and tp.effdate >= '1-Jul-2005' > This SQL is not correct because the effdate condition needs to be in the "on" clause, not the "where" clause. But the "on" clause is generated internally by NHibernate, and I haven't found a way to alter it. Is there a way? > btw... tradeprice is a lazy init bag on trade object > related forum topic: http://forum.hibernate.org/viewtopic.php?t=952606&highlight=outer+join -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-15 14:54:34
|
[ http://jira.nhibernate.org/browse/NH-383?page=3Dall ] =20 Sergey Koshcheyev closed NH-383: -------------------------------- Resolution: Fixed Added a simple implementation of IDisposable. The class will not fail if an= y functions are called on a disposed ISessionFactory though. > SessionFactory should implement System.IDisposable > -------------------------------------------------- > > Key: NH-383 > URL: http://jira.nhibernate.org/browse/NH-383 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.2.0.Beta2, 1.0-rc1 > Reporter: Pierre Henri Kuat=C3=A9 > Priority: Minor > Fix For: 1.2.0.CR1 > > Not very important, but it seems logical that NHibernate.ISessionFactory = inherits from System.IDisposable! --=20 This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-15 13:29:25
|
[ http://jira.nhibernate.org/browse/NH-780?page=all ] Sergey Koshcheyev closed NH-780: -------------------------------- Resolution: Fixed > Obsolete code in the tips 'n tricks > ----------------------------------- > > Key: NH-780 > URL: http://jira.nhibernate.org/browse/NH-780 > Project: NHibernate > Type: Improvement > Components: Documentation > Versions: 1.2.0.Beta1 > Reporter: Guy Mahieu > Priority: Trivial > Fix For: 1.2.0.CR1 > > From the docs: > <blockquote/> > 11.13. Tips & Tricks > You can count the number of query results without actually returning them: > <code> > IEnumerator countEn = session.Enumerable("select count(*) from ....").GetEnumerator(); > countEn.MoveNext(); > int count = (int) countEn.Current; > </code> > </blockquote> > Other than looking like a workaround, this uses obsolete code (session.Enumerable); it might be better to change it to: > <code> > int count = (int) session.CreateQuery("select count(*) from ...").UniqueResult(); > </code> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-15 13:23:26
|
[ http://jira.nhibernate.org/browse/NH-730?page=all ] Sergey Koshcheyev closed NH-730: -------------------------------- Resolution: Fixed > make the bag Attribute protected instead of private in PersistentBag.cs > ----------------------------------------------------------------------- > > Key: NH-730 > URL: http://jira.nhibernate.org/browse/NH-730 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.2.0.Beta1 > Reporter: Franz Meier > Priority: Trivial > Fix For: 1.2.0.CR1 > > File PersistentBag.cs > Original: > public class PersistentBag : AbstractPersistentCollection, IList > { > private IList bag; > should be: > public class PersistentBag : AbstractPersistentCollection, IList > { > protected IList bag; > The big problem is, that if you create you own collections, > you need to access the underlying bag! > The PersistentSet is correct! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: NHibernate J. <mik...@us...> - 2006-11-15 13:21:28
|
[ http://jira.nhibernate.org/browse/NH-808?page=comments#action_14412 ] Sergey Koshcheyev commented on NH-808: -------------------------------------- See SelectParser.cs, line 148: if( "*".Equals( token ) && !afterAggregatePath) { q.AddSelectScalar( NHibernateUtil.Int32 ); } //special case > Type of count(*) should be Int64 > -------------------------------- > > Key: NH-808 > URL: http://jira.nhibernate.org/browse/NH-808 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.2.0.Beta2 > Reporter: Sergey Koshcheyev > Priority: Trivial > Fix For: 1.2.0.CR1 > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.nhibernate.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
35 messages has been excluded from this view by a project administrator.
