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-12-15 08:59:36
|
[ http://jira.nhibernate.org/browse/NH-828?page=comments#action_14610 ] Sergey Koshcheyev commented on NH-828: -------------------------------------- Implementation finished, need to wait until somebody tests it. Also need to document the functionality. > Port connection release mode from H3 > ------------------------------------ > > Key: NH-828 > URL: http://jira.nhibernate.org/browse/NH-828 > Project: NHibernate > Type: New Feature > Components: Core > Versions: 1.2.0.Beta2 > Reporter: Sergey Koshcheyev > Fix For: 1.2.0.Beta3 > -- 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-12-14 05:34:36
|
[ http://jira.nhibernate.org/browse/NH-836?page=all ] Sergey Koshcheyev resolved NH-836: ---------------------------------- Resolution: Not an Issue Doesn't look like a bug to me. Not-found="ignore" means that if there's an invalid foreign key in the database, it will just be ignored, as if there was a null there instead. It certainly doesn't change the semantics of PersistentGenericMap vs. ordinary Dictionary. If you're sure it's a bug and you have a test case to prove it, I will reopen the issue. > PersistentGenericMap doesn't really apply "not-found" > ----------------------------------------------------- > > Key: NH-836 > URL: http://jira.nhibernate.org/browse/NH-836 > Project: NHibernate > Type: Bug > Versions: 1.2.0.Beta2 > Reporter: Jerry Haltom > Priority: Trivial > > <map > name="InputItems" > lazy="true" > table="MemberInputItem"> > <key > column="MemberId" /> > <index-many-to-many > column="MemberInputId" > class="ISIS.Data.Core.MemberInput, ISIS.Data" /> > <one-to-many > not-found="ignore" > class="ISIS.Data.Core.MemberInputItem, ISIS.Data" /> > </map> > Though "not-found" is set to ignore on the one-to-many, it's meaning is a bit unclear. It doesn't actually prevent the indexer of the PersistentGenericMap from throwing an exception. I'm unsure of the intended purpose. Dictionaries now provide a TryGetValue which can be used by code which doesn't want an exception to be thrown in this circumstance. Should this not be the recommended way users of hte dictionary expect no results? -- 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-12-13 22:40:31
|
PersistentGenericMap doesn't really apply "not-found"
-----------------------------------------------------
Key: NH-836
URL: http://jira.nhibernate.org/browse/NH-836
Project: NHibernate
Type: Bug
Versions: 1.2.0.Beta2
Reporter: Jerry Haltom
Priority: Trivial
<map
name="InputItems"
lazy="true"
table="MemberInputItem">
<key
column="MemberId" />
<index-many-to-many
column="MemberInputId"
class="ISIS.Data.Core.MemberInput, ISIS.Data" />
<one-to-many
not-found="ignore"
class="ISIS.Data.Core.MemberInputItem, ISIS.Data" />
</map>
Though "not-found" is set to ignore on the one-to-many, it's meaning is a bit unclear. It doesn't actually prevent the indexer of the PersistentGenericMap from throwing an exception. I'm unsure of the intended purpose. Dictionaries now provide a TryGetValue which can be used by code which doesn't want an exception to be thrown in this circumstance. Should this not be the recommended way users of hte dictionary expect no results?
--
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-12-13 21:10:32
|
[ http://jira.nhibernate.org/browse/NH-239?page=all ] Sergey Koshcheyev updated NH-239: --------------------------------- Comment: was deleted > Issue with PersistentEnumType.ReturnedClass > ------------------------------------------- > > Key: NH-239 > URL: http://jira.nhibernate.org/browse/NH-239 > Project: NHibernate > Type: Bug > Components: Core > Reporter: Jenser Almeida > Assignee: Mike Doerfler > Fix For: beta-0.8.4 > Attachments: EnumTest.zip > > A query like "select new Result(t.str1, t.enumType) from Test t" will not work because a issue with the System.Type of enum's. > Test case e relevant mapping's will be atached. > PS If there is anything not clear please tell me. I am not a good english writer -- 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-12-13 20:55:33
|
[ http://jira.nhibernate.org/browse/NH-692?page=all ] Sergey Koshcheyev updated NH-692: --------------------------------- Comment: was deleted > Problem when display a Collection in a Combobox (C#) > ---------------------------------------------------- > > Key: NH-692 > URL: http://jira.nhibernate.org/browse/NH-692 > Project: NHibernate > Type: Bug > Components: Core > Versions: 1.2.0.Beta1, 1.2.0.Alpha1 > Reporter: Franz Meier > Attachments: bugreport.zip > > The Problem occurs when I retrieve data from a table and put the List as the Datasource of a combobox > eg: > coDomain.DataSource = session.CreateQuery("from TDomain").List(); > //then i set display member: > coDomain.DisplayMember = "DomainName"; > After that only the first value is displayed correctly in the combobox, > all other values are display as the Class Name (it seems that the TOString() Function is called). see atteched bug.jpg > The Interesting thing is, this problems existist since 1.2.0Alpha1 and also on the current cvs snapshot. > the old 1.0.2 is working perfectly. > The Domain Class has an included bag, if i remove the bag the whole thing is also working. > Strange! > It think this is an proxy issue! -- 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-12-13 20:55:32
|
[ http://jira.nhibernate.org/browse/NH-467?page=all ] Sergey Koshcheyev updated NH-467: --------------------------------- Comment: was deleted > Many-to-one ignores "WHERE" class mapping element on associated Class > --------------------------------------------------------------------- > > Key: NH-467 > URL: http://jira.nhibernate.org/browse/NH-467 > Project: NHibernate > Type: Bug > Components: Core > Versions: 1.0 > Reporter: Alexei > Fix For: 1.2.0.Alpha1 > > For example a Employee->User association > Class Employee: > <class name="Employee, MyApp" table="Employee" where="inactive=0" > > ... > <many-to-one name="User" class="User, MyApp" > column="UserId" unique="true" not-null="false" > > Class User: > <class name="User, MyApp" table="Users" where="inactive=0" > > Will generate SQL: > SELECT... FROM Employee this LEFT OUTER JOIN Users user1_ ON this.UserId=user1_.id WHERE this.inactive=0 > The User objects will be retrived ignoring the "inactive" flag on Users table. Similar behaviour with <bag>, <one-to-one> and others. -- 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-12-11 15:17:35
|
[ http://jira.nhibernate.org/browse/NH-784?page=comments#action_14580 ] Sergey Koshcheyev commented on NH-784: -------------------------------------- The last two problems should actually lead to an exception being thrown. If they don't in your case, I'd like to see a test case. > NHibernate should throw exception on failed driver load > ------------------------------------------------------- > > Key: NH-784 > URL: http://jira.nhibernate.org/browse/NH-784 > Project: NHibernate > Type: Improvement > Components: Data Providers > Versions: 1.2.0.Beta2 > Reporter: Al Twohill > Priority: Trivial > Fix For: 1.2.0.Beta3 > > For full background on where this issue arises from, see http://forum.hibernate.org/viewtopic.php?t=966582&highlight= > When Configuration.Configure() is called, if NHibernate is unable to load a database driver for whatever reason (missing dll, incorrect hibernate.cfg.xml, etc) it falls back to returning a UserSuppliedConnectionProvider without an ADO.Net connection attached to it. This causes any use of Session (eg accessing database) to throw an exception. This is extremely difficult to debug, as there is absolutely no indication as to why a UserSuppliedConnectionProvider is returned. > I propose that instead of returning a UserSuppliedConnectionProvider, NHibernate should throw an exception along the lines of "Cannot Load Driver", and give a reason why. -- 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-12-09 17:44:43
|
[ http://jira.nhibernate.org/browse/NH-467?page=all ] Sergey Koshcheyev updated NH-467: --------------------------------- Comment: was deleted > Many-to-one ignores "WHERE" class mapping element on associated Class > --------------------------------------------------------------------- > > Key: NH-467 > URL: http://jira.nhibernate.org/browse/NH-467 > Project: NHibernate > Type: Bug > Components: Core > Versions: 1.0 > Reporter: Alexei > Fix For: 1.2.0.Alpha1 > > For example a Employee->User association > Class Employee: > <class name="Employee, MyApp" table="Employee" where="inactive=0" > > ... > <many-to-one name="User" class="User, MyApp" > column="UserId" unique="true" not-null="false" > > Class User: > <class name="User, MyApp" table="Users" where="inactive=0" > > Will generate SQL: > SELECT... FROM Employee this LEFT OUTER JOIN Users user1_ ON this.UserId=user1_.id WHERE this.inactive=0 > The User objects will be retrived ignoring the "inactive" flag on Users table. Similar behaviour with <bag>, <one-to-one> and others. -- 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-12-09 17:44:39
|
[ http://jira.nhibernate.org/browse/NH-766?page=all ] Sergey Koshcheyev updated NH-766: --------------------------------- Comment: was deleted > Avoid joins on <composite-key><key-many-to-one> queries > ------------------------------------------------------- > > Key: NH-766 > URL: http://jira.nhibernate.org/browse/NH-766 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.0.2 > Reporter: Kirk Wylie > Priority: Trivial > Fix For: LATER > > This is being promoted from something I posted on the NHibernate forums. > Using NHibernate 1.0.2.0 against Oracle 9. > I'm working with an existing schema which isn't using surrogate keys, and I have a composite key of the form: > <class name="CalculatedRating" ...> > <composite-id> > <key-property name="EffectiveDate" column="EFFECTIVE_DATE"/> > <key-many-to-one name="FdeOrganization" column="ORGANIZATION_ID" .../> > </composite-id> > ... > </class> > Using this query: > from CalculatedRating cr > inner join fetch cr.FdeOrganization fdeOrg > left join fetch fdeOrg.Attributes as attribute > inner join fetch attribute.AttributeType > where cr.EffectiveDate = > (select max(cr2.EffectiveDate) > from CalculatedRating cr2 > where cr2.EffectiveDate >= :EffectiveDate) > order by cr.FdeOrganization.OrgId > NHibernate is quite correctly generating the SQL necessary to completely manifest the CalculatedRating element in a single query. However, after executing that query, it then still proceeds to do the N+1 select on FdeOrganization. > As in this application I'm actually using quite a few cases where I'm successfully using the inner join fetch technique against FdeOrganization, I can only assume that this is a problem related to key-many-to-one rather than many-to-one. > After further investigation, I can establish that Hibernate 3.1.3 exposes the exact same functionality. I'm filing this first against NHibernate since that's where I first discovered it, however, since it affects Hibernate as well it might be better filed against that, and I can do so if needed. -- 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-12-08 20:22:34
|
[ http://jira.nhibernate.org/browse/NH-736?page=all ] Ayende Rahien resolved NH-736: ------------------------------ Resolution: Fixed Fixed in 2524 > Caching cause leaking of entities data from one session factory to another > -------------------------------------------------------------------------- > > Key: NH-736 > URL: http://jira.nhibernate.org/browse/NH-736 > Project: NHibernate > Type: Bug > Components: Core, Contrib > Versions: 1.0.2, 1.2.0.Alpha1, 1.2.0.Beta1 > Reporter: Ayende Rahien > Assignee: Ayende Rahien > Attachments: add-cache-region-prefix-to-2nd-level-cache-2.patch, add-cache-region-prefix-to-2nd-level-cache.patch, add-session-name-awareness-to-2nd-level-cache.patch > > Assuming that I've an Employee #5 in two session factories, and caching is enabled, it is possible that data that was loaded in one session factory will be returned from the second. > This is because the generated cache key is the same, and the cache space is shared in all implementations. > Should use the session factory name to distingiush between the caches, since that will allow using the cache in distributed scenarios yet maintain the seperation between seperate session factories. -- 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-12-08 20:20:38
|
[ http://jira.nhibernate.org/browse/NH-736?page=comments#action_14561 ] Ayende Rahien commented on NH-736: ---------------------------------- more specifically, I am talking about it not being used for entities. For query cache, it is used, but not when storing the entity data itself. > Caching cause leaking of entities data from one session factory to another > -------------------------------------------------------------------------- > > Key: NH-736 > URL: http://jira.nhibernate.org/browse/NH-736 > Project: NHibernate > Type: Bug > Components: Core, Contrib > Versions: 1.0.2, 1.2.0.Alpha1, 1.2.0.Beta1 > Reporter: Ayende Rahien > Assignee: Ayende Rahien > Attachments: add-cache-region-prefix-to-2nd-level-cache-2.patch, add-cache-region-prefix-to-2nd-level-cache.patch, add-session-name-awareness-to-2nd-level-cache.patch > > Assuming that I've an Employee #5 in two session factories, and caching is enabled, it is possible that data that was loaded in one session factory will be returned from the second. > This is because the generated cache key is the same, and the cache space is shared in all implementations. > Should use the session factory name to distingiush between the caches, since that will allow using the cache in distributed scenarios yet maintain the seperation between seperate session factories. -- 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-12-08 20:18:40
|
[ http://jira.nhibernate.org/browse/NH-736?page=all ] Ayende Rahien reopened NH-736: ------------------------------ Looks like this is really an issue, the caches are not using regionPrefix, although it is passed to them. > Caching cause leaking of entities data from one session factory to another > -------------------------------------------------------------------------- > > Key: NH-736 > URL: http://jira.nhibernate.org/browse/NH-736 > Project: NHibernate > Type: Bug > Components: Core, Contrib > Versions: 1.0.2, 1.2.0.Alpha1, 1.2.0.Beta1 > Reporter: Ayende Rahien > Assignee: Ayende Rahien > Attachments: add-cache-region-prefix-to-2nd-level-cache-2.patch, add-cache-region-prefix-to-2nd-level-cache.patch, add-session-name-awareness-to-2nd-level-cache.patch > > Assuming that I've an Employee #5 in two session factories, and caching is enabled, it is possible that data that was loaded in one session factory will be returned from the second. > This is because the generated cache key is the same, and the cache space is shared in all implementations. > Should use the session factory name to distingiush between the caches, since that will allow using the cache in distributed scenarios yet maintain the seperation between seperate session factories. -- 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-12-07 18:48:30
|
[ http://jira.nhibernate.org/browse/NH-467?page=all ] Christian Bauer updated NH-467: ------------------------------- Comment: was deleted > Many-to-one ignores "WHERE" class mapping element on associated Class > --------------------------------------------------------------------- > > Key: NH-467 > URL: http://jira.nhibernate.org/browse/NH-467 > Project: NHibernate > Type: Bug > Components: Core > Versions: 1.0 > Reporter: Alexei > Fix For: 1.2.0.Alpha1 > > For example a Employee->User association > Class Employee: > <class name="Employee, MyApp" table="Employee" where="inactive=0" > > ... > <many-to-one name="User" class="User, MyApp" > column="UserId" unique="true" not-null="false" > > Class User: > <class name="User, MyApp" table="Users" where="inactive=0" > > Will generate SQL: > SELECT... FROM Employee this LEFT OUTER JOIN Users user1_ ON this.UserId=user1_.id WHERE this.inactive=0 > The User objects will be retrived ignoring the "inactive" flag on Users table. Similar behaviour with <bag>, <one-to-one> and others. -- 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-12-07 18:48:30
|
[ http://jira.nhibernate.org/browse/NH-435?page=all ] Christian Bauer updated NH-435: ------------------------------- Comment: was deleted > Outer join fetch sends unnecessary SELECT to database to get parent > --------------------------------------------------------------------- > > Key: NH-435 > URL: http://jira.nhibernate.org/browse/NH-435 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.0 > Reporter: Xianfeng Lu > Attachments: nh-435.rar > > In a bi-directional parent-children relationship, if I call session.Find() to outer join fetch like this > IList lst = session.Find("from Parent p left outer join fetch p.Children"); > I saw a SELECT...FROM Parent LEFT OUTER JOIN Children to fetch both parent object and child objects, but after it there is a SELECT...FROM Parent WHERE... to get children's parent from database. The second SQL is really not necessary since the parent has been in memory after the 1st SQL. > I don't know if the 2nd level cache can avoid the 2nd SELECT hitting database any way. -- 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-12-07 17:23:33
|
[ http://jira.nhibernate.org/browse/NH-648?page=3Dall ] Pierre Henri Kuat=C3=A9 updated NH-648: ---------------------------------- Fix Version: (was: LATER) 1.2.0.Beta3 > Discriminator attribute allowed for class (not only property, field or in= dexer) > -------------------------------------------------------------------------= ------ > > Key: NH-648 > URL: http://jira.nhibernate.org/browse/NH-648 > Project: NHibernate > Type: Improvement > Components: Contrib > Versions: 1.2.0.Alpha1 > Reporter: Christoph Wienands > Assignee: Pierre Henri Kuat=C3=A9 > Priority: Trivial > Fix For: 1.2.0.Beta3 > > Hello Kpix, > I have another improvement request for you. I defined a base class Domain= Object, which already defines an ID (note that PascalCaseMUnderScore is a c= ustom FieldAccessor so I can use strong typing instead of strings): > =09public class DomainObjectInt : DomainObject<int> > =09{ > =09=09[Id(0, Name =3D "ID", Column =3D "ID", TypeType =3D typeof(Int32), = UnsavedValue =3D "0", > =09=09=09AccessType =3D typeof(PascalCaseMUnderScore))] > =09=09[Generator(1, Class =3D "identity")] > =09=09public override int ID > =09=09{ > =09=09=09get { return base.ID; } > =09=09} > =09} > Now when I want to define inheritance hierarchies I run into trouble: > =09[Class(0, NameType =3D typeof(Operation), Table =3D "[Operation]", Laz= y =3D false)] > =09[Discriminator(1, Column =3D "Discriminator")] > =09public abstract class Operation : DomainObjectInt, IOperation > =09{ > =09} > I'd like to place the discriminator right at the top with the class defin= ition. However, it's only valid on property, indexer or field. The workarou= nd is to place it e.g. on top of the first member variable but that's misle= ading when someone looks at the code. > Is there a reason why I couldn't place that attribute on top of the class= ? > Thanks, Christoph --=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-12-06 14:21:43
|
Document MultiQuery
--------------------
Key: NH-835
URL: http://jira.nhibernate.org/browse/NH-835
Project: NHibernate
Type: Improvement
Components: Documentation
Versions: 1.2.0.Beta2
Reporter: Ayende Rahien
Priority: Trivial
Fix For: 1.2.0.Beta3
--
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-12-06 13:59:36
|
Document hibernate.connection.connection_string_name
----------------------------------------------------
Key: NH-834
URL: http://jira.nhibernate.org/browse/NH-834
Project: NHibernate
Type: Task
Components: Documentation
Versions: 1.2.0.Beta2
Reporter: Sergey Koshcheyev
Priority: Trivial
Fix For: 1.2.0.Beta3
--
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-12-06 13:57:41
|
Document SQL Server command batching functionality
--------------------------------------------------
Key: NH-833
URL: http://jira.nhibernate.org/browse/NH-833
Project: NHibernate
Type: Task
Components: Documentation
Versions: 1.2.0.Beta2
Reporter: Sergey Koshcheyev
Priority: Trivial
Fix For: 1.2.0.Beta3
--
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.
