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-13 18:04:30
|
[ http://jira.nhibernate.org/browse/NH-802?page=comments#action_14376 ] Sergey Koshcheyev commented on NH-802: -------------------------------------- Opinions are nice, but what about concrete arguments? > 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 > > 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-13 18:04:25
|
[ http://jira.nhibernate.org/browse/NH-519?page=all ] Sergey Koshcheyev updated NH-519: --------------------------------- Fix Version: LATER > Cache and reuse prepared statements > ----------------------------------- > > Key: NH-519 > URL: http://jira.nhibernate.org/browse/NH-519 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.0.1 > Reporter: Geert Verbakel > Priority: Minor > Fix For: LATER > Attachments: prepared statements.txt > > Same bug as NH-140 (reintroduced in 1.0.1.0) > The same statement (for eagerly loading many-to-one objects) is prepared everytime it is executed. > In 0.6.0.0, a statement would be prepared once and reused: > * declare @P1 int > set @P1=443 > exec sp_prepexec @P1 output, N'@p0 uniqueidentifier', N'SELECT ..... WHERE Id= @p0', @p0 = '611475FC-FC66-4C3A-8C2D-0BB27AF8BDCA' > * exec sp_execute 443, @p0 = '23BBE372-74E7-4EFB-B605-9DDA90E02462' > (multiple times) > In 1.0.1.0, this is no longer the case. It is always sp_prepexec > I have set hibernate.prepare_sql to true, which result in statements being prepared, but not cached... > See attached file for Query analyzer details -- 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-13 18:04:25
|
[ http://jira.nhibernate.org/browse/NH-514?page=all ] Sergey Koshcheyev updated NH-514: --------------------------------- Fix Version: LATER > 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-13 18:04:23
|
[ http://jira.nhibernate.org/browse/NH-473?page=all ] Sergey Koshcheyev updated NH-473: --------------------------------- Fix Version: LATER > order-by in <bag> is ignored if FetchMode is Join > ------------------------------------------------- > > Key: NH-473 > URL: http://jira.nhibernate.org/browse/NH-473 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.0.1 > Reporter: Stefan Lieser > Fix For: LATER > > Given the following mapping: > <class name="Example.Book, Example" table="Books" > > <id name="Id" column="RecID" type="System.Int64" unsaved-value="0"> > <generator class="native" /> > </id> > <property name="Name" column="Name" type="System.String" /> > <bag name="Pages" lazy="true" order-by="PageNo" > > <key column="BookID" /> > <one-to-many class="Example.Page, Example" /> > </bag> > </class> > If I retrieve an object of class Book and let the Pages collection lazy load, everything is ok. The Pages collection is loaded on acces and ordered by PageNo: > ICriteria criteria = session.CreateCriteria(typeof(Book)); > criteria.Add(Expression.Eq("Name", name)); > Book book = criteria.UniqueResult() as Book; > ... > int count = book.Pages.Count; // collection is loaded with "order by PageNo" in the SQL statemenet > But if I retrieve the Book with FetchMode.Join on the Pages collection, the order-by is ignored: > ICriteria criteria = session.CreateCriteria(typeof(Book)); > criteria.Add(Expression.Eq("Name", name)); > criteria.SetFetchMode("Details", FetchMode.Join); > Book book = criteria.UniqueResult() as Book; // collection is loaded without "order by" in the SQL > Sincerely, > Stefan Lieser -- 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-13 18:04:23
|
[ http://jira.nhibernate.org/browse/NH-804?page=all ] Sergey Koshcheyev updated NH-804: --------------------------------- Fix Version: LATER > Implement the SUBSELECT FETCH and BATCH FETCH > --------------------------------------------- > > Key: NH-804 > URL: http://jira.nhibernate.org/browse/NH-804 > Project: NHibernate > Type: New Feature > Components: Core > Versions: 1.2.0.Beta2 > Reporter: Franz Meier > Fix For: LATER > > like in hibernate 3.x > sess.CreateQuery("from Book b SUBSELECT FETCH b.publisher") > sess.CreateQuery("from Book b BATCH FETCH SIZE=5 b.publisher") > the strange thing is, that you can configure it in the mapping xml file, > but you cannot use it in the CreateQuery -- 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-13 18:04:21
|
[ http://jira.nhibernate.org/browse/NH-727?page=all ] Sergey Koshcheyev updated NH-727: --------------------------------- Fix Version: LATER > Allow using sql-insert with generator class="identity" > ------------------------------------------------------ > > Key: NH-727 > URL: http://jira.nhibernate.org/browse/NH-727 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.2.0.Beta1 > Reporter: Sergey Koshcheyev > Priority: Minor > Fix For: LATER > -- 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-13 18:04:19
|
[ http://jira.nhibernate.org/browse/NH-586?page=all ] Sergey Koshcheyev closed NH-586: -------------------------------- Resolution: Fixed Option 3 implemented in Beta2. > Alternative way to specify the type for select new > -------------------------------------------------- > > Key: NH-586 > URL: http://jira.nhibernate.org/browse/NH-586 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.0.2 > Reporter: Dragos Nuta > > I think that everybody agrees that adding the imports to mappings is kind of cumbersome. It is difficult to maintain and the fact that they cannot be specified in a dedicate mapping file is even more annoying in my opinion. What would you think of these alternative ways to specify the type for the mapping? > 1. session.CreateQuery( "select new Dummy(o.f1, o.f2) from MyEntity o", typeof(Dummy) ).List(); > With this you can give the Type instance as a parameter > 2. session.CreateQuery<Dummy>( "select new Dummy(o.f1, o.f2) from MyEntity o").List(); > With this you can use generics to return a typed object (with a known Type) and can also be used for normal queries to return typed lists. > 3. session.CreateQuery( "select o.f1, o.f2 from MyEntity o" ).IntoDTO( typeof(Dummy) ).List(); > With this you express separately that the data will be obtained into a Dummy Type. > 4. session.CreateQuery<Dummy>("select o.f1, o.f2 from MyEntity o").List(); > With this NH can look at the select clause and if Dummy is not persistent entity can treat it as a DTO a perform a select new. > My favorite would be 1 or 3. > Or least it would be great to add imports dynamically at run-time: > sessionFactory.Imports.Add( "Dummy", typeof(Dummy) ); > What do you think? > PS: Let me know if the change would be adopted because I can start 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-13 18:04:17
|
[ http://jira.nhibernate.org/browse/NH-364?page=all ] Sergey Koshcheyev updated NH-364: --------------------------------- Fix Version: LATER Version: 1.2.0.Beta2 > IdBag doesn't work with Identity columns > ---------------------------------------- > > Key: NH-364 > URL: http://jira.nhibernate.org/browse/NH-364 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.2.0.Beta2, beta-0.9.1 > Reporter: Paul Hatcher > Priority: Minor > Fix For: LATER > > Take two classes Link and Category and give Link an IList of Categories. Map this as an idbag and make the generator of the collection-id be identity. > It saves the Link and Category objects correctly, but gives a casting exception on saving CategoryLink. > Looking at the code, BasicCollectionPersister is used and during GenerateInsertRowString this takes no account of the fact that we have an IdentifierBag collection and that there might be an identity column. > The 2.1 java code exhibits the same problem, so I don't quite get how this should work. I've included a test case against the bug number in the test project. > I could have done something wrong here, but then the docs need fixing :-) -- 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-13 18:04:14
|
[ http://jira.nhibernate.org/browse/NH-421?page=all ] Sergey Koshcheyev updated NH-421: --------------------------------- Fix Version: 1.2.0.CR1 > Dialect Improvements > -------------------- > > Key: NH-421 > URL: http://jira.nhibernate.org/browse/NH-421 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.0 > Reporter: Mike Doerfler > Fix For: LATER > > While working on the if exists and drop table issue for MS SQL I came across some areas to make improvements. > It would be good to take advantage of the String.Format() capabilities instead of doing string building in Dialect based on multiple properties being true. The best example of this is the GetDropTableString(string tableName). It would be good to add a virtual property to Dialect called DropTableString{get;} that would be a string that could be formatted with one value. Other Dialects could implement the property DropTableString instead of the properties SupportsIfExistsBeforeTableName and SupportsIfExistsAfterTableName. > This same thing applies to GetDropForeignKeyConstraintString(string constraintName). It would also be good to pass the table name so the signature becomes GetDropForeignKeyConstraintString(string tableName, string constraintName) and that would remove the ddl from NHibernate.Mapping.ForeignKey.SqlDropString. The way it is coded now (without modifying a public API) does not allow for an IF EXISTS check before altering the table. The sql to drop a FK in MS SQL is : > if exists (select * from dbo.sysobjects where id = object_id(N'{constraintName}') and OBJECTPROPERTY(id, N'IsForeignKey') = 1) > ALTER TABLE {tableName} DROP CONSTRAINT {constraintName} > GO -- 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-13 18:04:12
|
[ http://jira.nhibernate.org/browse/NH-466?page=all ] Sergey Koshcheyev updated NH-466: --------------------------------- Fix Version: LATER Version: 1.2.0.Beta2 > Add <join> mapping element to map one class to several tables > ------------------------------------------------------------- > > Key: NH-466 > URL: http://jira.nhibernate.org/browse/NH-466 > Project: NHibernate > Type: New Feature > Components: Core > Versions: 1.2.0.Beta2 > Reporter: Alexei > Fix For: LATER > > It would be nice to be able to map properties of one class to several tables as Hibernate 3.0 does with a <join> element. > An important feature when working with legacy data models shared by existing applications. -- 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-13 18:04:10
|
[ http://jira.nhibernate.org/browse/NH-435?page=all ] Sergey Koshcheyev closed NH-435: -------------------------------- Resolution: Incomplete > 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-11-13 18:04:09
|
[ http://jira.nhibernate.org/browse/NH-803?page=all ] Sergey Koshcheyev updated NH-803: --------------------------------- Fix Version: LATER Version: 1.2.0.Beta2 > Support DML type batch sql statements > ------------------------------------- > > Key: NH-803 > URL: http://jira.nhibernate.org/browse/NH-803 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.2.0.Beta2 > Reporter: manuj > Priority: Minor > Fix For: LATER > > It will be really nice if we could support DML type batch statements like hibernate 3.2 > e.g. bulk update, bulk delete etc. -- 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-13 18:04:05
|
[ http://jira.nhibernate.org/browse/NH-769?page=all ] Sergey Koshcheyev updated NH-769: --------------------------------- Fix Version: LATER > Improve serialization of Session > -------------------------------- > > Key: NH-769 > URL: http://jira.nhibernate.org/browse/NH-769 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.2.0.Beta2 > Reporter: Peter Smulovics > Priority: Minor > Fix For: LATER > > Serialization of Session object is done using the default methods, resulting in time and space consuming binary objects. Technologies like FastSerializer ( http://www.codeproject.com/dotnet/FastSerializer.asp ) may help a lot. -- 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-13 18:04:05
|
[ http://jira.nhibernate.org/browse/NH-791?page=all ] Sergey Koshcheyev updated NH-791: --------------------------------- Fix Version: LATER Description: In order to easily accommodate custom collections NHibernate should offer an option to always wrap the collection instance from the target object. Basically when NHibernate creates a persistent collection from a transient collection it will take the existing collection and wrap it's own persistent collection type around that collection so that the user's collection still exists underneath and performs its own logic. Add a new configuration option to all collection types called always-wrap which has a type of true/false and defaults to false. When a new persistent object is loaded from the database for this type if always-wrap is true it will take the already created collection and wrap it with a new persistent collection instead of instantiating its own collection type which implements the same interface. As long as the user collection implements the correct ISet/IDictionary/IList interface the the user would be done adding their custom collection. For more information see the following post: http://forum.hibernate.org/viewtopic.php?t=966861 was: In order to easily accommodate custom collections NHibernate should offer an option to always wrap the collection instance from the target object. Basically when NHibernate creates a persistent collection from a transient collection it will take the existing collection and wrap it's own persistent collection type around that collection so that the user's collection still exists underneath and performs its own logic. Add a new configuration option to all collection types called always-wrap which has a type of true/false and defaults to false. When a new persistent object is loaded from the database for this type if always-wrap is true it will take the already created collection and wrap it with a new persistent collection instead of instantiating its own collection type which implements the same interface. As long as the user collection implements the correct ISet/IDictionary/IList interface the the user would be done adding their custom collection. For more information see the following post: http://forum.hibernate.org/viewtopic.php?t=966861 > Add always-wrap As a Configuration Option On Collections > -------------------------------------------------------- > > Key: NH-791 > URL: http://jira.nhibernate.org/browse/NH-791 > Project: NHibernate > Type: New Feature > Components: Core > Versions: 1.2.0.Beta2, 1.2.0.Alpha1, 1.2.0.Beta1 > Reporter: John Chapman > Priority: Minor > Fix For: LATER > > In order to easily accommodate custom collections NHibernate should offer an option to always wrap the collection instance from the target object. Basically when NHibernate creates a persistent collection from a transient collection it will take the existing collection and wrap it's own persistent collection type around that collection so that the user's collection still exists underneath and performs its own logic. > Add a new configuration option to all collection types called always-wrap which has a type of true/false and defaults to false. When a new persistent object is loaded from the database for this type if always-wrap is true it will take the already created collection and wrap it with a new persistent collection instead of instantiating its own collection type which implements the same interface. > As long as the user collection implements the correct ISet/IDictionary/IList interface the the user would be done adding their custom collection. > For more information see the following post: > http://forum.hibernate.org/viewtopic.php?t=966861 -- 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-13 18:04:05
|
[ http://jira.nhibernate.org/browse/NH-763?page=all ] Sergey Koshcheyev updated NH-763: --------------------------------- Fix Version: LATER > NHibernate Does Not Recognize Dependent Resources > ------------------------------------------------- > > Key: NH-763 > URL: http://jira.nhibernate.org/browse/NH-763 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.2.0.Beta1 > Reporter: Chris Moore > Priority: Minor > Fix For: LATER > Attachments: HbmResFinder.txt > > SUMMARY: NHibernate will not recognize mapping resource files that are dependent upon their associated domain classes. > DETAIL: Visual Studio/MSBuild uses a "dependency" scheme that can associate a resource file with a given class. This mechanism is used, for instance, to bind RESX files with their associated forms. Among other things, this allows the environment to display the dependent resource files as child nodes of the associated form classes. For example, to associate the hibernate resource "Person.hbm.xml" resource with the file "Person.cs" one would configure the MBBuild file thusly: > <Compile Include="Person.cs"/> > <EmbeddedResource Include="Person.hbm.xml"> > <DependentUpon>Person.cs</DependentUpon> > </EmbeddedResource> > In addition to cleaning up the tree in the project view, this approach also has the advantage of declaratively advertising the extant association between a map file and a domain class. > Now, here is the core of the problem: The compiler will embed the mapping resource with the name of the type with which it is associated "Person" instead of the full name of the file "Person.hbm.xml". In this case, NHibernate will not be able to find the "Person" resource is not found and the assembly registration process will fail because NHibernate currently discriminates mapping resources via the file extension "hbm.xml". > SOLUTION: The assumption that the resource will include the "hbm.xml" extension is made in two places: near line 627 in NHibernate.Cfg.Configuration and near line 55 in NHibernate.Cfg.AssemblyHbmOrderer. Replacing this logic to discriminate, instead, on the content of the file (e.g. determine with a given resource is an xml file with xmlns="urn:nhibernate-mapping-2.0"). > OTHER BENEFITS: Removing the requirment that mapping resource files must be named with the "hbm.xml" extension opens up Visual Studio integration possibilities. One could for example, integrate a custom tool that is designed to edit files of type "*.hbm". > REMARKS: If this fix is accepted, I would be willing to provide the code that would perform this content-based discrimination. Most likely, I would write a "MapResourceFinder" utility class that would do this work. -- 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-13 18:04:05
|
[ http://jira.nhibernate.org/browse/NH-717?page=all ] Sergey Koshcheyev updated NH-717: --------------------------------- Fix Version: LATER > Please add Predicate generic set operations to ISet<T> > ------------------------------------------------------ > > Key: NH-717 > URL: http://jira.nhibernate.org/browse/NH-717 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.2.0.Alpha1 > Reporter: Michael Teper > Priority: Minor > Fix For: LATER > > Things like Find<T>, etc. > http://msdn2.microsoft.com/en-us/library/d9hw1as6.aspx > Thanks! -- 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-13 18:04:03
|
[ http://jira.nhibernate.org/browse/NH-688?page=all ] Sergey Koshcheyev updated NH-688: --------------------------------- Fix Version: 1.2.0.CR1 > On-line NHibernate API References > --------------------------------- > > Key: NH-688 > URL: http://jira.nhibernate.org/browse/NH-688 > Project: NHibernate > Type: Task > Components: Documentation > Versions: 1.2.0.Alpha1 > Reporter: Sergey Koshcheyev > Priority: Minor > Fix For: 1.2.0.CR1 > > From: http://forum.hibernate.org/viewtopic.php?t=963024 > Hi all! > Could the developers provide an on-line version of NHibernate API docs? I built one myself but it's too huge to be put on sourceforge - 120MB including my project's, using sandcastle. > (I need to reference to the classes/methods from my project's manual) -- 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-13 18:04:03
|
[ http://jira.nhibernate.org/browse/NH-714?page=all ] Sergey Koshcheyev updated NH-714: --------------------------------- Fix Version: LATER > Persistor Inheritance for Dynamic Proxies > ----------------------------------------- > > Key: NH-714 > URL: http://jira.nhibernate.org/browse/NH-714 > Project: NHibernate > Type: New Feature > Components: Core > Versions: 1.2.0.Beta2, 1.0.2 > Reporter: Curtis Schlak > Priority: Minor > Fix For: LATER > Attachments: version-1.x.patches.zip > > I have the opportunity to work with NHibernate in a project at work. We use dynamically-generated proxy objects for use in our application which renders the static NHibernate mapping files useless. We have found that a new feature allowing the framework to search the inheritance hierarchy for persisters used by the proxy's base class allows the transparent use of the dynamically-generated proxy objects. Please find in the attached ZIP archive file two patches that we have used to implement this feature, one patch for the 1.0 release branch and one for the upcoming 1.2 release branch in your development trunk. > USAGE > To activate this feature, add the property "hibernate.inherit_persisters" with a value of "true" to the configuration. > CHANGES > In Version 1.0 Release Branch > * In NHibernate.Test-1.1 project: > - Added the virtual "ExtraProperties" property to the TestCase class. > - Added the virtual "ExtraProperties" property to the TestCase class. > - Added the "Subclass\InheritPersisterFixture.cs" class to test the functionality. > * In NHibernate-1.1 project: > - Changed the "GetPersister(Type)" method in the SessionFactoryImpl class to search for inherited persisters. > In Trunk, along with the changes above, > * In NHibernate.Test-1.1 project: > - Cleaned up the NHibernate.Tests-1.1.csproj to compile. > - Removed the App.config file due to incompatibility with the .NET 1.1 framwork. > - Added the App-1.1.config file for .NET 1.1 Framework compatibility. > - Changed the projects PreBuildEvent to copy the App-1.1.config file. > * In NHibernate-1.1 project: > - Cleaned up the NHibernate-1.1.csproj file to compile. -- 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-13 18:04:03
|
[ http://jira.nhibernate.org/browse/NH-752?page=all ] Sergey Koshcheyev updated NH-752: --------------------------------- Fix Version: 1.2.0.CR1 Version: 1.2.0.Beta2 > Informix Dialect > ---------------- > > Key: NH-752 > URL: http://jira.nhibernate.org/browse/NH-752 > Project: NHibernate > Type: New Feature > Components: Data Providers > Versions: 1.2.0.Beta2 > Reporter: Robert Sosnowski > Priority: Minor > Fix For: 1.2.0.CR1 > Attachments: InformixDialect.zip > > I've made Informix dialect. I've tested it on 1.0.2 with Odbc driver (I haven't used native Informix driver because I had some problems with it). > Dialect for 1.2.0 untested but it should work. The only difference is IdentitySelectString property in 1.0.2 changed to GetIdentitySelectString method in 1.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-13 18:04:01
|
[ http://jira.nhibernate.org/browse/NH-573?page=all ] Sergey Koshcheyev updated NH-573: --------------------------------- Fix Version: LATER Component: Core > New method to "completely load" a proxy. > ---------------------------------------- > > Key: NH-573 > URL: http://jira.nhibernate.org/browse/NH-573 > Project: NHibernate > Type: New Feature > Components: Core > Versions: 1.0.2 > Reporter: Jerry Haltom > Priority: Minor > Fix For: LATER > > A lot of the time I find myself in a position to need to know the runtime type of a mapped class. Proxies break this by design, which isn't itself a problem, but I need a way around it. > Contract.Client is of type Client. Institution inherits from Client. Contract.Client may be an Institution. The only way to know is to attempt to load the Client object. The proxy however subclasses Client, without loading Institution. This results in the expression "contract.Client is Institution" never being valid. > I'm not suggesting you fix this, as it's not really fixable by my view. I just need a quick way to get around it. I suggest a method like the following: > session.Get(contract, "Client") > This expression, or one similar to it, would immediatly go to the database and retrieve the proper type for the Client property, and set it. It would make situations like this much easier to work around. > This method should also fix up any other references to the same instance in the entire session. -- 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-13 18:04:00
|
[ http://jira.nhibernate.org/browse/NH-271?page=all ] Sergey Koshcheyev closed NH-271: -------------------------------- Resolution: Not an Issue No demand for the fix. > Need a way to specify precision for nullable decimal > ---------------------------------------------------- > > Key: NH-271 > URL: http://jira.nhibernate.org/browse/NH-271 > Project: NHibernate > Type: Improvement > Components: Contrib > Versions: beta-0.8 > Reporter: Sergey Koshcheyev > Priority: Minor > > This describes the problem: > http://nhibernate.sourceforge.net/forum/viewtopic.php?t=5 > There should be a way to specify precision for NullableDecimal, just as there is for decimal. -- 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-13 18:04:00
|
[ http://jira.nhibernate.org/browse/NH-729?page=all ] Sergey Koshcheyev updated NH-729: --------------------------------- Fix Version: 1.2.0.CR1 > Add ICurrentSessionContext implementation for ASP.NET apps. > ----------------------------------------------------------- > > Key: NH-729 > URL: http://jira.nhibernate.org/browse/NH-729 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.2.0.Beta1 > Reporter: Sergey Koshcheyev > Priority: Minor > 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-13 18:03:50
|
[ http://jira.nhibernate.org/browse/NH-653?page=3Dall ] Sergey Koshcheyev updated NH-653: --------------------------------- Fix Version: LATER > NHibernate.Mapping.Attributes - User interfaces > ----------------------------------------------- > > Key: NH-653 > URL: http://jira.nhibernate.org/browse/NH-653 > Project: NHibernate > Type: New Feature > Components: Contrib > Versions: 1.2.0.Alpha1 > Reporter: Pierre Henri Kuat=C3=A9 > Assignee: Pierre Henri Kuat=C3=A9 > Priority: Minor > Fix For: LATER > > It would be interesting to add a NAnt task and maybe a Console/Windows ap= plication to generate mapping information from any assembly and save it in = a file/directory. > This feature would make it possible to not use NHMA at runtime (which is = a good thing because it makes the initialization of NHibernate a little bit= faster). --=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-13 18:03:49
|
[ http://jira.nhibernate.org/browse/NH-693?page=all ] Sergey Koshcheyev closed NH-693: -------------------------------- Resolution: Incomplete I can't see what is the cause of the error. > Better Error Msg > ---------------- > > Key: NH-693 > URL: http://jira.nhibernate.org/browse/NH-693 > Project: NHibernate > Type: Improvement > Components: Core > Reporter: Dru Sellers > Priority: Minor > > 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-13 18:03:47
|
[ http://jira.nhibernate.org/browse/NH-224?page=all ] Sergey Koshcheyev updated NH-224: --------------------------------- Fix Version: LATER Version: 1.2.0.Beta2 > Reference Type OR Property conditions produce bad JOIN syntax for HQL Queries against parent Objects > ---------------------------------------------------------------------------------------------------- > > Key: NH-224 > URL: http://jira.nhibernate.org/browse/NH-224 > Project: NHibernate > Type: Improvement > Components: Core > Versions: 1.2.0.Beta2, alpha > Environment: Oracle + ODP.NET 10.1.0.3.0 > C# - Client/Server > Reporter: Jeff Mayeur > Assignee: Mike Doerfler > Priority: Minor > Fix For: LATER > > REF FORUM: http://sourceforge.net/forum/forum.php?thread_id=1232722&forum_id=252014 > Summary: When using properies of Reference Type as part of an HQL query where the Child Ref Type Property is within the scope of an OR, the JOIN ID = ID is placed within the bounds of the SQL OR condition, producing fautly results. > Additionally, it seems that an ORDER BY using the Child Ref Type properties produces invalid SQL, as the ORDER BY column is not included in the select statement. > From the forumn post: > --- Let me preface this by saying, while I think of this aa a bug, I fully understand the point of view that "if you used it like it was meant to be used you wouldn't have this issue." > > > Problem: > For many-to-one joins, if an HQL contains an evaluation criteria for this Obj in an OR Expression the join is not properly restricted. Below is sample HQL, classes, hbm files, and the output SQL. [ note these are abstractions from real code, so forgive and typeos... trust me there really is an issue here. ] > > Of course the HQL could be written differently to avoid this issue, but we are implementing a "Query Tool" to allow users to define their own queries via a click and drag UI. Additionally the problem can be addressed by "pre-parsing" the query for issues like this, but at that point, why not go all the way to SQL. > > HQL: > SELECT item > FROM ParentObj AS item > WHERE ( > LOWER( item.SomeText ) = 'fooText' > and ( > item.SomeNumber = 55 > or ( > LOWER( item.FirstLookup.Description ) = 'my firstDesc' > and ( > item.SomeNumber = 56 > or item.ModelYear = 57) > ) > ) > ) order by item.Id asc > > > /*********** NHIBERNATE 6 *************************/ > select > parentob0_.MUID as MUID > , parentob0_.SOME_TEXT as SOME2_ > , parentob0_.SOME_NUMBER as SOME3_ > , parentob0_.OTHER_VALUE as OTHER4_ > , parentob0_.FIRST_LOOKUP_ID as FIRST5_ > , parentob0_.SECOND_LOOKUP_ID as SECOND6_ > , parentob0_.THIRD_LOOKUP_ID as THIRD7_ > FROM PARENT_OBJ parentob0_ > , LOOKUP_OBJ lookupobj2_ > where ( > ( LOWER( parentob0_.SOME_TEXT ) = 'fooText' ) > and ( > ( parentob0_.SOME_NUMBER = 55 ) > or ( > ( > LOWER( lookupob2_.LOOKUP_DESC ) = 'my firstDesc' > and parentob0_.FIRST_LOOKUP_ID = lookupob2_.LOOKUP_ID > ) > and ( > ( parentob0_.SOME_NUMBER = 56 ) > or( parentob0_.SOME_NUMBER = 57 ) > ) > ) > ) > ) > order by parentob0_.MUID asc; > /*********** BETTER [ HAND BUILT ]*************************/ > select > parentob0_.MUID as MUID > , parentob0_.SOME_TEXT as SOME2_ > , parentob0_.SOME_NUMBER as SOME3_ > , parentob0_.OTHER_VALUE as OTHER4_ > , parentob0_.FIRST_LOOKUP_ID as FIRST5_ > , parentob0_.SECOND_LOOKUP_ID as SECOND6_ > , parentob0_.THIRD_LOOKUP_ID as THIRD7_ > FROM PARENT_OBJ parentob0_ > , LOOKUP_OBJ lookupobj2_ > where ( > ( LOWER( parentob0_.SOME_TEXT ) = 'fooText' ) > and ( > ( parentob0_.SOME_NUMBER = 55 ) > or ( > LOWER( lookupob2_.LOOKUP_DESC ) = 'my firstDesc' > and ( > ( parentob0_.SOME_NUMBER = 56 ) > or( parentob0_.SOME_NUMBER = 57 ) > ) > ) > ) > ) > AND parentob0_.FIRST_LOOKUP_ID = lookupob2_.LOOKUP_ID /* JOIN**/ > order by parentob0_.MUID asc; > > > CLASSES/HBM > > using System; > > namespace NHibernateIssue { > /// <summary> > /// Summary description for ParentObj. > /// </summary> > public class ParentObj { > private int id; > private string someText; > private int someNumber; > private string otherValue; > > private LookupObj firstLookup; > private LookupObj secondLookup; > private LookupObj thirdLookup; > > /// <summary> > /// Unique ID [ORA_DB SEQUENCE] > /// </summary> > public int Id { > get { return id; } > set { id = value; } > } > > /// <summary> > /// A text Value [ORA_DB VARCHAR2] > /// </summary> > public string SomeText { > get { return someText; } > set { someText = value; } > } > > /// <summary> > /// A number Value [ORA_DB NUMBER(38,0)] > /// </summary> > public int SomeNumber { > get { return someNumber; } > set { someNumber = value; } > } > > /// <summary> > /// Another text Value [ORA_DB VARCHAR2] > /// </summary> > public string OtherValue { > get { return otherValue; } > set { otherValue = value; } > } > > /// <summary> > /// A Lookup Item, ( DB table PARENT_OBJ is related to LOOKUP_OBJ by FIRST_LOOKUP_ID == LOOKUP_ID ) > /// </summary> > public LookupObj FirstLookup { > get { return firstLookup; } > set { firstLookup = value; } > } > > /// <summary> > /// A Lookup Item, ( DB table PARENT_OBJ is related to LOOKUP_OBJ by FIRST_LOOKUP_ID == LOOKUP_ID ) > /// </summary> > public LookupObj SecondLookup { > get { return secondLookup; } > set { secondLookup = value; } > } > > /// <summary> > /// A Lookup Item, ( DB table PARENT_OBJ is related to LOOKUP_OBJ by FIRST_LOOKUP_ID == LOOKUP_ID ) > /// </summary> > public LookupObj Thirdookup { > get { return thirdLookup; } > set { thirdLookup = value; } > } > > > public ParentObj() { > } > > > } > } > > > > > using System; > > namespace NHibernateIssue { > /// <summary> > /// Summary description for ChildObj. > /// </summary> > public class LookupObj { > private int lookupId; > private string description; > > /// <summary> > /// Unique "LOOKUP" ID > /// </summary> > public int LookupId { > get { return this.lookupId; } > set { this.lookupId = value; } > } > > /// <summary> > /// "LOOKUP" Description > /// </summary> > public string Description { > get { return this.description; } > set { this.description = value; } > } > > public LookupObj() { > } > > } > } > > > > <?xml version="1.0" encoding="utf-8" ?> > <hibernate-mapping xmlns="urn:nhibernate-mapping-2.0"> > <class name="NHibernateIssue.ParentObj, NHibernateIssue" table="PARENT_OBJ"> > <id name="Id" column="MUID" unsaved-value="0"> > <generator class="sequence"> > <param name="sequence">UID_SEQ</param> > </generator> > </id> > <property name="SomeText" column="SOME_TEXT" not-null="false" /> > <property name="SomeNumber" column="SOME_NUMBER" type="NHibernate.DomainModel.NHSpecific.NullInt32UserType, NHibernate.DomainModel" not-null="false" /> > <property name="OtherValue" column="OTHER_VALUE" not-null="false" /> > <many-to-one name="FirstLookup" class="NHibernateIssue.LookupObj, NHibernateIssue" > column="FIRST_LOOKUP_ID" cascade="none"/> > <many-to-one name="SecondLookup" class="NHibernateIssue.LookupObj, NHibernateIssue" > column="SECOND_LOOKUP_ID" cascade="none"/> > <many-to-one name="ThirdLookup" class="NHibernateIssue.LookupObj, NHibernateIssue" > column="THIRD_LOOKUP_ID" cascade="none"/> > </class> > </hibernate-mapping> > > > > > <?xml version="1.0" encoding="utf-8" ?> > <hibernate-mapping xmlns="urn:nhibernate-mapping-2.0"> > <class name="NHibernateIssue.LookupObj, NHibernateIssue" table="LOOKUP_OBJ"> > <id name="LookupId" column="LOOKUP_ID" unsaved-value="0"> > <generator class="sequence"> > <param name="sequence">LID</param> > </generator> > </id> > <property name="Description" column="LOOKUP_DESC" /> > </class> > </hibernate-mapping> -- 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 |