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: Marko K. (J. <nh...@gm...> - 2011-04-14 09:58:11
|
Validator displays wrong error "The 'inverse' attribute is not declared." when "not-null" is missing ---------------------------------------------------------------------------------------------------- Key: NHV-115 URL: http://216.121.112.228/browse/NHV-115 Project: NHibernate.Validator Issue Type: Bug Components: Core Affects Versions: 1.3.0 GA Reporter: Marko Kovačić I had a bidirectional mapping, with this on the child side: <many-to-one name="Subjekt" column="SubjektId" inverse="true" /> But I kept ketting error message: XML validation error: The 'inverse' attribute is not declared. And that drived me crazy as the inverse attribute is obviously there... finally I've tried not-null="true" and the message dissapeared. So please just update the error message so people don't get stuck on this. Thank you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Kirill M. (JIRA) <nh...@gm...> - 2011-04-14 08:01:13
|
HQL + theta-style join + Enumerable() + select only one entity = strange proxies' behaviour while iterating ----------------------------------------------------------------------------------------------------------- Key: NH-2650 URL: http://216.121.112.228/browse/NH-2650 Project: NHibernate Issue Type: Bug Components: DataProviders / Dialects Affects Versions: 3.1.0 Reporter: Kirill Medvedev Priority: Major I've created a test which consists of two classes: Man: <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" assembly="Domain" namespace="Domain" default-lazy="true"> <class name="Man" table="Men"> <id name="Id" column="Id"> <generator class="native"/> </id> <many-to-one name="Owner" class="Owner" column="OwnerId" cascade="save-update"/> <property name="Name"/> </class> </hibernate-mapping> Owner: <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" assembly="Domain" namespace="Domain" default-lazy="true"> <class name="Owner" table="Owners"> <id name="Id" column="Id"> <generator class="native"/> </id> <property name="Name"/> <bag name="Men" cascade="save-update"> <key column="OwnerID"/> <one-to-many class="Man"/> </bag> </class> </hibernate-mapping> If I write a simple hql-query without theta-joins, I get a lazily-loaded collection of proxies: IEnumerable<Man> men = session.CreateQuery("from Man").Enumerable<Man>(); I can iterate through this collection without loading proxies: foreach (Man each in men) { //No code here, only iterating... Proxies are not loaded here, as expected. } But when I add theta-style join to this query... IEnumerable<Man> result = session.CreateQuery("select m from Man m left join m.Owner").Enumerable<Man>(); NHibernate generates acceptable TSQL and builds SafetyEnumerable collection select man0_.Id as col_0_0_ from Men man0_ left outer join Owners owner1_ on man0_.OwnerId = owner1_.Id but (!) when I add iterating logic without accessing to any properties foreach (Man each in men) { //No code here! Only iterating through elements } new queries go to database each iteration, and load each entity: SELECT man0_.Id as Id1_0_, man0_.OwnerId as OwnerId1_0_, man0_.Name as Name1_0_ FROM Men man0_ WHERE man0_.Id = 5098 /* @p0 */ Therefore I can't even convert this IEnumerable<Man> to List<Man> without loading the whole list of objects, because List constructor iterates through IEnumerable collection to add this collection to itself //public List(IEnumerable<T> collection) - constructor while (enumerator.MoveNext()) { this.Add(enumerator.Current); } Question: Is this behaviour designed to behave such way intentionally? It's strange that different hql queries return SafetyEnumerable collection which behaves differently while iterating through it (in case of non-theta joined queries, collection's entities are not loaded while iterating through it (without accessing any properties), but in theta-joined queries, entities are loaded while iterating through collection). Strange proxies' behaviour. Thank you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Patrick E. (JIRA) <nh...@gm...> - 2011-04-14 04:11:12
|
[ http://216.121.112.228/browse/NH-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Earl resolved NH-2540. ------------------------------ Resolution: Fixed Fix Version/s: 3.2.0Beta1 This no longer appears to be a problem on the trunk. I did not track down exactly which revision fixed it. > Linq generates invalid boolean case statements (was: Linq ignoring configured query-substitutions) > -------------------------------------------------------------------------------------------------- > > Key: NH-2540 > URL: http://216.121.112.228/browse/NH-2540 > Project: NHibernate > Issue Type: Bug > Components: Linq Provider > Affects Versions: 3.0.0.GA > Reporter: Yogesh Jagota > Assignee: Patrick Earl > Priority: Major > Fix For: 3.2.0Beta1 > > Attachments: Generated SQL.txt, NH2540.zip > > > Query: > var items = (from b in session.Query<InvoiceDetail>() > where b.Customer == AddressedToCustomer && b.IsCreditNote == !addInvoices > orderby b.DueDate , b.InvoiceNumber > select b).ToList(); > This query works fine on 3.0.0.1002, but fails on 3.0.0.4000. Generated SQL is attached. > Reason: > I am using a convention to convert bools into ints (true=1, false=0). The previous version is doing this conversion, the newer version isn't. The bool is converted to a string in the newer version (as is the default in sqlite driver), but it should be converted to int according to the convention. > From generated SQL: > "!addInvoices" is passed as a string in the sql query and int in the previous version: > 3.0.0.1002: @p1 = True [Type: Int32 (0)] > 3.0.0.4000: @p1 = 'True' [Type: String (0)] > Also, the IsCreditNote database field is compared to 'true' and 'false' in the new version, and with 1 and 0 in the previous version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Harald M. M. (J. <nh...@gm...> - 2011-04-13 19:09:22
|
[ http://216.121.112.228/browse/NH-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20905#action_20905 ] Harald M. Müller commented on NH-2583: -------------------------------------- A fix for this along the lines of my code probably would also fix NH-2451, wouldn't it? > Query with || operator and navigations (many-to-one) creates wrong joins > ------------------------------------------------------------------------ > > Key: NH-2583 > URL: http://216.121.112.228/browse/NH-2583 > Project: NHibernate > Issue Type: Bug > Components: Linq Provider > Affects Versions: 3.1.0 > Reporter: Harald M. Müller > Assignee: Patrick Earl > Priority: Critical > Attachments: JoinOptimizationForPureOuterJoinSemantics.txt, LogicalOperatorsInNHibernateLinq.txt, NH-2583a.diff, NH-2583b.diff, NH-2583c.diff, NH-2583d.diff, NH-2583e.diff, NH-2583f.diff, NH-2583g.diff, NH-2583g2ndTry.patch, NH2583.7z, NHib3.0.0Or.zip > > > The following query > var result = session.Query<MyBO>() > .Where(bo => > (bo.BO1 != null && bo.BO1.I2 == 101) || > (bo.BO2 != null && bo.BO2.J2 == 203) > ) > ; > result.ToList(); > creates the following SQL on SQL Server 2008 (with .Net 4.0, MsSql2008Dialect): > exec sp_executesql N'select mybo0_.Id as Id0_, mybo0_.Name as Name0_, mybo0_.BO1Key as BO3_0_, mybo0_.OtherBO1Key as OtherBO4_0_, mybo0_.BO2Key as BO5_0_ from MyBO mybo0_, MyRef1 myref1x1_, MyRef2 myref2x2_ where mybo0_.BO1Key=myref1x1_.Id and mybo0_.BO2Key=myref2x2_.Id and ((mybo0_.BO1Key is not null) and myref1x1_.I2=@p0 or (mybo0_.BO2Key is not null) and myref2x2_.J2=@p1)',N'@p0 int,@p1 int',@p0=101,@p1=203 > or, formatted: > SELECT mybo0_.id AS id0_, > mybo0_.name AS name0_, > mybo0_.bo1key AS bo3_0_, > mybo0_.otherbo1key AS otherbo4_0_, > mybo0_.bo2key AS bo5_0_ > FROM mybo mybo0_, > myref1 myref1x1_, > myref2 myref2x2_ > WHERE mybo0_.bo1key = myref1x1_.id -- inner (table) join > AND mybo0_.bo2key = myref2x2_.id -- also inner (table) join > AND ( ( mybo0_.bo1key IS NOT NULL ) > AND myref1x1_.i2 = @p0 > OR ( mybo0_.bo2key IS NOT NULL ) > AND myref2x2_.j2 = @p1 ) > This is wrong if the reference to ref1 or ref2 is null. The attachment contains a small project that shows the problem. > AFAIK, the problem has been always present when using HQL navigations (a.b.c....); it is - somewhat implicitly - documented in seciotn 13.7.: > Compound path expressions make the where clause extremely powerful. Consider: > from Eg.Cat cat where cat.Mate.Name is not null > This query translates to an SQL query with a table (inner) join. > In HQL, one can claim that this is "a feature" (and the workaround is to use manual JOINs). With Linq, this is no longer possible - the semantics of the || operator should be correctly implemented, shouldn't it? Therefore, I dared to mark this bug as "Critical". > (... or - please - show me that I'm wrong and that || + navigation work as expected!). > Remark: In our project, which started with NHib 0.99 six years ago, we(I) wrote a complete expression framework akin to Linq (but only with conditions, not with expressions). When we found this problem, I rewrote the HQL builder so that it then created (and still creates) correct INNER or OUTER JOINs, depending on the expression tree (one has to consider Is-Null/Is-Not-Null operators and Not nodes above these, as far as I remember ... I'd have to look into our code). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Harald M. M. (J. <nh...@gm...> - 2011-04-13 17:47:19
|
[ http://216.121.112.228/browse/NH-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20904#action_20904 ] Harald M. Müller commented on NH-2648: -------------------------------------- I looked a little bit in the code and found the following in HqlSqlWalker.g: fromElement! ...: | je=joinElement -> //$je i.e., the return $je of a joinElement is commented, so it returns the null tree. Probably, global joins are handled via some global variable machinery (there is a call to CreateFromJoinElement(...) inside joinElement's production), but this appears not to work for subqueries. Maybe this helps to solve this issue. > HQL with joins in sub-select creates wrong SQL > ---------------------------------------------- > > Key: NH-2648 > URL: http://216.121.112.228/browse/NH-2648 > Project: NHibernate > Issue Type: Bug > Components: Core > Affects Versions: 3.2.0Beta1 > Reporter: Harald M. Müller > Priority: Critical > Attachments: HQL_MissingJoinInExists.zip > > > The following query is translated to wrong SQL - the join is missing from the sub-select: > SELECT ROOT FROM NHibernate.Test.NHSpecificTest.HQL_MissingJoinInExists.Sheet AS ROOT > WHERE (EXISTS (FROM NHibernate.Test.NHSpecificTest.HQL_MissingJoinInExists.Shelf AS inv > JOIN ROOT.Folder AS ROOT_Folder > WHERE (((ROOT_Folder.Shelf) = (inv) AND inv.Id = 1)) )) > AND ROOT.Name = 'SomeName' > (The query was created by a HQL generator of ours - hence the superfluous parentheses). The exceotion is: > NHibernate.Exceptions.GenericADOException : could not execute query > [ select sheet0_.Id as Id2_, sheet0_.Name as Name2_, sheet0_.Folder as Folder2_ from Sheet sheet0_ where (exists (select shelf1_.Id from Shelf shelf1_ where folder2_.Shelf=shelf1_.Id and shelf1_.Id=1)) and sheet0_.Name='SomeName' ] > [SQL: select sheet0_.Id as Id2_, sheet0_.Name as Name2_, sheet0_.Folder as Folder2_ from Sheet sheet0_ where (exists (select shelf1_.Id from Shelf shelf1_ where folder2_.Shelf=shelf1_.Id and shelf1_.Id=1)) and sheet0_.Name='SomeName'] > ----> System.Data.SqlClient.SqlException : The multi-part identifier "folder2_.Shelf" could not be bound. > Since NHib 0.99 and in Hibernate, it has been possible to use joins inside subqueries. HQL allows it, and therefore, it should produce correct SQL (both syntactically and semantically). Actually, joins in subqueries are *necessary* if there are OR or NOT operators inside the subquery (some simpler queries can be rewritten with all Joins at top-level). > I consider this bug critical because there is no workaround for > * HQL generated for earlier NHib versions > * manual HQL that needs OR or NOT inside a subquery > * (I assume) the correct translation of Linq's .Any in the NHib.Linq provider > I have attached a test case that shows the behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Fabio M. (JIRA) <nh...@gm...> - 2011-04-13 17:35:10
|
[ http://216.121.112.228/browse/NH-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabio Maulo resolved NH-2644. ----------------------------- Resolution: Fixed Fix Version/s: 3.2.0Beta1 > schemaaction is not supported in joinedsubclass > ----------------------------------------------- > > Key: NH-2644 > URL: http://216.121.112.228/browse/NH-2644 > Project: NHibernate > Issue Type: Improvement > Components: Core > Affects Versions: 3.2.0Alpha1 > Reporter: Giovanni Bismondo > Priority: Minor > Fix For: 3.2.0Beta1 > > > schemaaction is not supported in joinedsubclass -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Fabio M. (JIRA) <nh...@gm...> - 2011-04-13 17:08:10
|
[ http://216.121.112.228/browse/NH-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabio Maulo resolved NH-2642. ----------------------------- Resolution: Fixed Fix Version/s: 3.2.0Beta1 > BatcherDataReaderWrapper.GetValue has a typo > -------------------------------------------- > > Key: NH-2642 > URL: http://216.121.112.228/browse/NH-2642 > Project: NHibernate > Issue Type: Bug > Components: Core > Affects Versions: 3.2.0Alpha1 > Reporter: Roger > Priority: Major > Fix For: 3.2.0Beta1 > > Attachments: batcherdatareaderwrapper.patch > > > The datareader decorator has a typo here > class BatcherDataReaderWrapper > object GetValue(int) > return reader.GETDECIMAL() > test + fix attached -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Jim H. J. (JIRA) <nh...@gm...> - 2011-04-13 13:25:23
|
[ http://216.121.112.228/browse/NH-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20903#action_20903 ] Jim Hale Jr. commented on NH-2526: ---------------------------------- You are correct - ASE 15 does choke on temp tables within transactions. Thanks for your work on this. > Sybase ASE 15 support > --------------------- > > Key: NH-2526 > URL: http://216.121.112.228/browse/NH-2526 > Project: NHibernate > Issue Type: Improvement > Components: DataProviders / Dialects > Affects Versions: 3.0.0.GA > Reporter: Jim Hale Jr. > Priority: Major > Fix For: 3.2.0Alpha1 > > Attachments: SybaseAdoNet2ClientDriver.cs, SybaseAse15Dialect.cs > > > The 3.0.0 release banished Sybase ASE users for reasons unknown to me. I understand the criticism of the 2.x and 3.0.0 release candidate implementations of the Sybase ASE dialect (yes they were bad), but at least they let ASE users use NHibernate. Better to have basic but functional support than no support at all. This is especially important for ASE users considering the lack of Entity support by Sybase for ASE. Removing ASE support forced NHibernate users to stay with the 2.12 release or pay for an Entity aware provider. The comments I read regarding the removal of ASE support - specifically regarding the merging of the ASE and ASA dialects - also make no sense to me. ASA and ASE are two different products with different keywords, SQL syntax, functions, and drivers. Their dialects cannot be merged! Same with the supposed support from the MS SQL 2000 dialect - this dialect uses MS keywords like 'TOP' that ASE does not support. > Attached is a port of the Sybase ASE Dialect from the Java Hibernate project along with support for the ADO.NET driver provided by Sybase. I am using it in a project currently and it at least appears to work. I am only using the most basic of NHibernate features though so additional testing would be nice. But it provides a start. > Tested against Sybase 15.0.3.0 using .NET 4.0 runtime and Sybase.AdoNet2.AseClient.dll driver (version 1.15.305.0). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Harald M. M. (J. <nh...@gm...> - 2011-04-13 10:01:10
|
Linq query with Any operator creates wrong results -------------------------------------------------- Key: NH-2649 URL: http://216.121.112.228/browse/NH-2649 Project: NHibernate Issue Type: Bug Components: Core, Linq Provider Affects Versions: 3.2.0Alpha1, 3.1.0, 3.0.0.GA, 3.2.0Beta1 Reporter: Harald M. Müller Priority: Critical Attachments: LinqAnyNotOr.zip Linq's .Any operator is apparently not translated to valid HQL. In the attachment, there are two test cases for an .Any behind a ! (not) and an .Any containing || (or): p => !p.Children.Any(c => c.Ref1 != null && c.Ref1.Name == "R1A") p => p.Children.Any(c => c.Ref1 != null && c.Ref1.Name == "R1A" || c.Ref2 != null && c.Ref2.Name == "R2A") I argue that this bug is critical because * the tests do *not* throw an exception, i.e., one might assume that the result is correct when it is not. * Workarounds are hard - they need to rewrite the complete expression. Especially when the expressions are built algorithmically (e.g. depending on user input), this may be next to impossible. I risk to predict that correctly translated HQL would then create wrong SQL - see issue NH-2648. Therefore, both these issues probably need to be solved at the same time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Harald M. M. (J. <nh...@gm...> - 2011-04-13 09:53:12
|
HQL with joins in sub-select creates wrong SQL ---------------------------------------------- Key: NH-2648 URL: http://216.121.112.228/browse/NH-2648 Project: NHibernate Issue Type: Bug Components: Core Affects Versions: 3.2.0Beta1 Reporter: Harald M. Müller Priority: Critical Attachments: HQL_MissingJoinInExists.zip The following query is translated to wrong SQL - the join is missing from the sub-select: SELECT ROOT FROM NHibernate.Test.NHSpecificTest.HQL_MissingJoinInExists.Sheet AS ROOT WHERE (EXISTS (FROM NHibernate.Test.NHSpecificTest.HQL_MissingJoinInExists.Shelf AS inv JOIN ROOT.Folder AS ROOT_Folder WHERE (((ROOT_Folder.Shelf) = (inv) AND inv.Id = 1)) )) AND ROOT.Name = 'SomeName' (The query was created by a HQL generator of ours - hence the superfluous parentheses). The exceotion is: NHibernate.Exceptions.GenericADOException : could not execute query [ select sheet0_.Id as Id2_, sheet0_.Name as Name2_, sheet0_.Folder as Folder2_ from Sheet sheet0_ where (exists (select shelf1_.Id from Shelf shelf1_ where folder2_.Shelf=shelf1_.Id and shelf1_.Id=1)) and sheet0_.Name='SomeName' ] [SQL: select sheet0_.Id as Id2_, sheet0_.Name as Name2_, sheet0_.Folder as Folder2_ from Sheet sheet0_ where (exists (select shelf1_.Id from Shelf shelf1_ where folder2_.Shelf=shelf1_.Id and shelf1_.Id=1)) and sheet0_.Name='SomeName'] ----> System.Data.SqlClient.SqlException : The multi-part identifier "folder2_.Shelf" could not be bound. Since NHib 0.99 and in Hibernate, it has been possible to use joins inside subqueries. HQL allows it, and therefore, it should produce correct SQL (both syntactically and semantically). Actually, joins in subqueries are *necessary* if there are OR or NOT operators inside the subquery (some simpler queries can be rewritten with all Joins at top-level). I consider this bug critical because there is no workaround for * HQL generated for earlier NHib versions * manual HQL that needs OR or NOT inside a subquery * (I assume) the correct translation of Linq's .Any in the NHib.Linq provider I have attached a test case that shows the behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Dario Q. (JIRA) <nh...@gm...> - 2011-04-13 03:18:09
|
[ http://216.121.112.228/browse/NHV-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dario Quintana closed NHV-114. ------------------------------ Resolution: Fixed fixed in r1672 > Remove dependency to Log4net > ---------------------------- > > Key: NHV-114 > URL: http://216.121.112.228/browse/NHV-114 > Project: NHibernate.Validator > Issue Type: Improvement > Components: Core > Affects Versions: 1.3.0 GA > Reporter: Dario Quintana > Assignee: Dario Quintana > > Replace to NHibernate.IInternalLogger -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Dario Q. (JIRA) <nh...@gm...> - 2011-04-13 03:14:09
|
Remove dependency to Log4net ---------------------------- Key: NHV-114 URL: http://216.121.112.228/browse/NHV-114 Project: NHibernate.Validator Issue Type: Improvement Components: Core Affects Versions: 1.3.0 GA Reporter: Dario Quintana Assignee: Dario Quintana Replace to NHibernate.IInternalLogger -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: David P. (JIRA) <nh...@gm...> - 2011-04-12 22:50:12
|
[ http://216.121.112.228/browse/NH-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20901#action_20901 ] David Popiashvili commented on NH-2647: --------------------------------------- I reproduced same issue with NHibernate 3.1.0 (Latest build) > Forward mapping and db types > ---------------------------- > > Key: NH-2647 > URL: http://216.121.112.228/browse/NH-2647 > Project: NHibernate > Issue Type: Bug > Components: Core > Affects Versions: 3.0.0.GA > Reporter: David Popiashvili > Priority: Minor > Attachments: NHibernateTest.rar > > > When we create database from our *.hbm mapping files, some of the data types are not mapped correctly to the db. For example, NHibernate ignores Precision and Scale properties for decimal type. Also there's strange behavior with AnsiString, for example this property > <property name="Username" length="15" type="AnsiString" /> is mapped as nvarchar(1) on the database, shouldn't it be varchar(15)? > We are using .NET 4, NHibernate 3.0 and SQL Server 2008 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: David P. (JIRA) <nh...@gm...> - 2011-04-12 22:48:04
|
[ http://216.121.112.228/browse/NH-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Popiashvili updated NH-2647: ---------------------------------- Attachment: NHibernateTest.rar Sample to demonstrate the buggy behavior of SchemaExport > Forward mapping and db types > ---------------------------- > > Key: NH-2647 > URL: http://216.121.112.228/browse/NH-2647 > Project: NHibernate > Issue Type: Bug > Components: Core > Affects Versions: 3.0.0.GA > Reporter: David Popiashvili > Priority: Minor > Attachments: NHibernateTest.rar > > > When we create database from our *.hbm mapping files, some of the data types are not mapped correctly to the db. For example, NHibernate ignores Precision and Scale properties for decimal type. Also there's strange behavior with AnsiString, for example this property > <property name="Username" length="15" type="AnsiString" /> is mapped as nvarchar(1) on the database, shouldn't it be varchar(15)? > We are using .NET 4, NHibernate 3.0 and SQL Server 2008 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Fabio M. (JIRA) <nh...@gm...> - 2011-04-12 22:29:16
|
[ http://216.121.112.228/browse/NH-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabio Maulo closed NH-2597. --------------------------- Resolution: Obsolete > GetLimitString "Nullable object must have a value" exception in DB2Dialect > -------------------------------------------------------------------------- > > Key: NH-2597 > URL: http://216.121.112.228/browse/NH-2597 > Project: NHibernate > Issue Type: Bug > Components: DataProviders / Dialects > Affects Versions: 3.0.0.GA > Reporter: Ted Lum > Attachments: NHibernate.zip > > > GetLimitString takes nullable parameters for offsetParameterIndex and limitParameterIndex. > When those parameters are null > pagingBuilder.Add("<= ").Add(Parameter.WithIndex(limitParameterIndex.Value)); > throws "Nullable object must have a value" exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Fabio M. (JIRA) <nh...@gm...> - 2011-04-12 22:29:04
|
[ http://216.121.112.228/browse/NH-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabio Maulo updated NH-2645: ---------------------------- Summary: Distinct is not supported by SelectClauseVisitor (was: NHibernate LINQ 3.0 connecting to Oracle ODP.Net Expression type 10005 is not supported by this SelectClauseVisitor.) > Distinct is not supported by SelectClauseVisitor > ------------------------------------------------ > > Key: NH-2645 > URL: http://216.121.112.228/browse/NH-2645 > Project: NHibernate > Issue Type: Bug > Components: Linq Provider > Affects Versions: 3.0.0.GA > Reporter: Paul Speranza > Priority: Minor > > I have the following LINQ query that is mapped to a view > QueryResult<List<PersonDemographic>> members = new QueryResult<List<PersonDemographic>>(); > var query = (from ms in this.Session.Query<MemberSummary>() > where ms.NameSearch.StartsWith(firstName.ToUpper()) > && ms.NameSearch2.StartsWith(lastName.ToUpper()) > select new PersonDemographic > { > FirstName = ms.FirstName.ToProperCase(), > LastName = ms.LastName.ToProperCase(), > PersonId = ms.Id, > Address = new Address > { > Line1 = ms.AddressLine1.ToProperCase(), > Line2 = ms.AddressLine2.ToProperCase(), > City = ms.City.ToProperCase(), > State = ms.State, > Zipcode = ms.Zipcode, > }, > PhoneNumber = new PhoneNumber > { > Number = string.IsNullOrWhiteSpace(ms.PhoneNumber) ? null : Regex.Replace(ms.PhoneNumber, @"(\d{3})(\d{3})(\d{4})", "$1-$2-$3") > } > }); > if (this.Session.Transaction.IsActive) > { > members.Data = query.Distinct().Take(15).ToList(); > } > else > { > using (var transaction = this.Session.BeginTransaction()) > { > members.Data = query.Distinct().Take(15).ToList(); > transaction.Commit(); > } > } > > The code is running under the transaction section. If I use it without a Distinct I have no problem. Adding the Distinct gives me an exception > {"Expression type 10005 is not supported by this SelectClauseVisitor."} > I can't find anything definitive. Can anyone help? > Thanks, Paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Fabio M. (JIRA) <nh...@gm...> - 2011-04-12 22:26:14
|
[ http://216.121.112.228/browse/NH-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabio Maulo updated NH-2645: ---------------------------- Priority: Minor (was: Critical) > NHibernate LINQ 3.0 connecting to Oracle ODP.Net Expression type 10005 is not supported by this SelectClauseVisitor. > -------------------------------------------------------------------------------------------------------------------- > > Key: NH-2645 > URL: http://216.121.112.228/browse/NH-2645 > Project: NHibernate > Issue Type: Bug > Components: Linq Provider > Affects Versions: 3.0.0.GA > Reporter: Paul Speranza > Priority: Minor > > I have the following LINQ query that is mapped to a view > QueryResult<List<PersonDemographic>> members = new QueryResult<List<PersonDemographic>>(); > var query = (from ms in this.Session.Query<MemberSummary>() > where ms.NameSearch.StartsWith(firstName.ToUpper()) > && ms.NameSearch2.StartsWith(lastName.ToUpper()) > select new PersonDemographic > { > FirstName = ms.FirstName.ToProperCase(), > LastName = ms.LastName.ToProperCase(), > PersonId = ms.Id, > Address = new Address > { > Line1 = ms.AddressLine1.ToProperCase(), > Line2 = ms.AddressLine2.ToProperCase(), > City = ms.City.ToProperCase(), > State = ms.State, > Zipcode = ms.Zipcode, > }, > PhoneNumber = new PhoneNumber > { > Number = string.IsNullOrWhiteSpace(ms.PhoneNumber) ? null : Regex.Replace(ms.PhoneNumber, @"(\d{3})(\d{3})(\d{4})", "$1-$2-$3") > } > }); > if (this.Session.Transaction.IsActive) > { > members.Data = query.Distinct().Take(15).ToList(); > } > else > { > using (var transaction = this.Session.BeginTransaction()) > { > members.Data = query.Distinct().Take(15).ToList(); > transaction.Commit(); > } > } > > The code is running under the transaction section. If I use it without a Distinct I have no problem. Adding the Distinct gives me an exception > {"Expression type 10005 is not supported by this SelectClauseVisitor."} > I can't find anything definitive. Can anyone help? > Thanks, Paul -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Fabio M. (JIRA) <nh...@gm...> - 2011-04-12 22:26:04
|
[ http://216.121.112.228/browse/NH-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabio Maulo updated NH-2634: ---------------------------- Summary: wrong select-query with many-to-one + cpmpositeId + pagination (was: NHibernate generates wrong select-query) > wrong select-query with many-to-one + cpmpositeId + pagination > -------------------------------------------------------------- > > Key: NH-2634 > URL: http://216.121.112.228/browse/NH-2634 > Project: NHibernate > Issue Type: Bug > Components: DataProviders / Dialects, QueryOver > Affects Versions: 3.1.0 > Reporter: Kirill Medvedev > Priority: Minor > Attachments: NH_Bug.zip > > > While transferring legacy project to NHibernate I found a bug... Nhibernate generates wrong SELECT query => GenericADOException occurs. See attachment. Thank you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Fabio M. (JIRA) <nh...@gm...> - 2011-04-12 22:24:15
|
[ http://216.121.112.228/browse/NH-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabio Maulo updated NH-2642: ---------------------------- Priority: Major (was: Trivial) > BatcherDataReaderWrapper.GetValue has a typo > -------------------------------------------- > > Key: NH-2642 > URL: http://216.121.112.228/browse/NH-2642 > Project: NHibernate > Issue Type: Bug > Components: Core > Affects Versions: 3.2.0Alpha1 > Reporter: Roger > Priority: Major > Attachments: batcherdatareaderwrapper.patch > > > The datareader decorator has a typo here > class BatcherDataReaderWrapper > object GetValue(int) > return reader.GETDECIMAL() > test + fix attached -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Fabio M. (JIRA) <nh...@gm...> - 2011-04-12 22:24:07
|
[ http://216.121.112.228/browse/NH-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabio Maulo updated NH-2647: ---------------------------- Priority: Minor (was: Major) We need your mappings and classes, since we have various tests to cover this situation. > Forward mapping and db types > ---------------------------- > > Key: NH-2647 > URL: http://216.121.112.228/browse/NH-2647 > Project: NHibernate > Issue Type: Bug > Components: Core > Affects Versions: 3.0.0.GA > Reporter: David Popiashvili > Priority: Minor > > When we create database from our *.hbm mapping files, some of the data types are not mapped correctly to the db. For example, NHibernate ignores Precision and Scale properties for decimal type. Also there's strange behavior with AnsiString, for example this property > <property name="Username" length="15" type="AnsiString" /> is mapped as nvarchar(1) on the database, shouldn't it be varchar(15)? > We are using .NET 4, NHibernate 3.0 and SQL Server 2008 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Fabio M. (JIRA) <nh...@gm...> - 2011-04-12 22:22:05
|
[ http://216.121.112.228/browse/NH-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabio Maulo updated NH-2634: ---------------------------- Component/s: (was: Core) DataProviders / Dialects > NHibernate generates wrong select-query > --------------------------------------- > > Key: NH-2634 > URL: http://216.121.112.228/browse/NH-2634 > Project: NHibernate > Issue Type: Bug > Components: DataProviders / Dialects, QueryOver > Affects Versions: 3.1.0 > Reporter: Kirill Medvedev > Priority: Minor > Attachments: NH_Bug.zip > > > While transferring legacy project to NHibernate I found a bug... Nhibernate generates wrong SELECT query => GenericADOException occurs. See attachment. Thank you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Fabio M. (JIRA) <nh...@gm...> - 2011-04-12 22:19:08
|
[ http://216.121.112.228/browse/NH-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabio Maulo closed NH-2646. --------------------------- Resolution: External Issue > Lazy Properties Causing An Exception With Castle Bytecode Provider > ------------------------------------------------------------------ > > Key: NH-2646 > URL: http://216.121.112.228/browse/NH-2646 > Project: NHibernate > Issue Type: Bug > Components: ByteCode providers > Affects Versions: 3.2.0Alpha1 > Reporter: Ricardo Peres > Attachments: UnitTests1.cs > > > If we are using the "old" Castle bytecode provider, lazy properties do not work, even inside lazy classes: when an entity is loaded, it crashes with a NotImplementedException ("Specified method is not supported."). > Attached is a sample. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: David P. (JIRA) <nh...@gm...> - 2011-04-12 22:07:04
|
Forward mapping and db types ---------------------------- Key: NH-2647 URL: http://216.121.112.228/browse/NH-2647 Project: NHibernate Issue Type: Bug Components: Core Affects Versions: 3.0.0.GA Reporter: David Popiashvili Priority: Major When we create database from our *.hbm mapping files, some of the data types are not mapped correctly to the db. For example, NHibernate ignores Precision and Scale properties for decimal type. Also there's strange behavior with AnsiString, for example this property <property name="Username" length="15" type="AnsiString" /> is mapped as nvarchar(1) on the database, shouldn't it be varchar(15)? We are using .NET 4, NHibernate 3.0 and SQL Server 2008 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Harald M. M. (J. <nh...@gm...> - 2011-04-12 20:48:11
|
[ http://216.121.112.228/browse/NH-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald M. Müller updated NH-2583: --------------------------------- Attachment: NH-2583g2ndTry.patch I could not apply my previous patch (NH-2583g.diff) to a newly loaded version of the trunk. So I modified the files there manually once more and created this new patch file. Hopefully it works better! > Query with || operator and navigations (many-to-one) creates wrong joins > ------------------------------------------------------------------------ > > Key: NH-2583 > URL: http://216.121.112.228/browse/NH-2583 > Project: NHibernate > Issue Type: Bug > Components: Linq Provider > Affects Versions: 3.1.0 > Reporter: Harald M. Müller > Assignee: Patrick Earl > Priority: Critical > Attachments: JoinOptimizationForPureOuterJoinSemantics.txt, LogicalOperatorsInNHibernateLinq.txt, NH-2583a.diff, NH-2583b.diff, NH-2583c.diff, NH-2583d.diff, NH-2583e.diff, NH-2583f.diff, NH-2583g.diff, NH-2583g2ndTry.patch, NH2583.7z, NHib3.0.0Or.zip > > > The following query > var result = session.Query<MyBO>() > .Where(bo => > (bo.BO1 != null && bo.BO1.I2 == 101) || > (bo.BO2 != null && bo.BO2.J2 == 203) > ) > ; > result.ToList(); > creates the following SQL on SQL Server 2008 (with .Net 4.0, MsSql2008Dialect): > exec sp_executesql N'select mybo0_.Id as Id0_, mybo0_.Name as Name0_, mybo0_.BO1Key as BO3_0_, mybo0_.OtherBO1Key as OtherBO4_0_, mybo0_.BO2Key as BO5_0_ from MyBO mybo0_, MyRef1 myref1x1_, MyRef2 myref2x2_ where mybo0_.BO1Key=myref1x1_.Id and mybo0_.BO2Key=myref2x2_.Id and ((mybo0_.BO1Key is not null) and myref1x1_.I2=@p0 or (mybo0_.BO2Key is not null) and myref2x2_.J2=@p1)',N'@p0 int,@p1 int',@p0=101,@p1=203 > or, formatted: > SELECT mybo0_.id AS id0_, > mybo0_.name AS name0_, > mybo0_.bo1key AS bo3_0_, > mybo0_.otherbo1key AS otherbo4_0_, > mybo0_.bo2key AS bo5_0_ > FROM mybo mybo0_, > myref1 myref1x1_, > myref2 myref2x2_ > WHERE mybo0_.bo1key = myref1x1_.id -- inner (table) join > AND mybo0_.bo2key = myref2x2_.id -- also inner (table) join > AND ( ( mybo0_.bo1key IS NOT NULL ) > AND myref1x1_.i2 = @p0 > OR ( mybo0_.bo2key IS NOT NULL ) > AND myref2x2_.j2 = @p1 ) > This is wrong if the reference to ref1 or ref2 is null. The attachment contains a small project that shows the problem. > AFAIK, the problem has been always present when using HQL navigations (a.b.c....); it is - somewhat implicitly - documented in seciotn 13.7.: > Compound path expressions make the where clause extremely powerful. Consider: > from Eg.Cat cat where cat.Mate.Name is not null > This query translates to an SQL query with a table (inner) join. > In HQL, one can claim that this is "a feature" (and the workaround is to use manual JOINs). With Linq, this is no longer possible - the semantics of the || operator should be correctly implemented, shouldn't it? Therefore, I dared to mark this bug as "Critical". > (... or - please - show me that I'm wrong and that || + navigation work as expected!). > Remark: In our project, which started with NHib 0.99 six years ago, we(I) wrote a complete expression framework akin to Linq (but only with conditions, not with expressions). When we found this problem, I rewrote the HQL builder so that it then created (and still creates) correct INNER or OUTER JOINs, depending on the expression tree (one has to consider Is-Null/Is-Not-Null operators and Not nodes above these, as far as I remember ... I'd have to look into our code). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Harald M. M. (J. <nh...@gm...> - 2011-04-12 19:26:43
|
[ http://216.121.112.228/browse/NH-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald M. Müller updated NH-2583: --------------------------------- Attachment: JoinOptimizationForPureOuterJoinSemantics.txt NH-2583g.diff This is now an implementation of "pure outer join semantics" for the logical operators ||, &&, and !. The document "JoinOptimizationForPureOuterJoinSemantics.txt" describes why and how inner joins are created by the code. All ca. 400 "relevant tests" (NHib.Linq and NH-2583 tests) are green. (However, there seem to be around 73 tests that are currently red on the trunk for other reasons - e.g. HqlBulkOperations: NHibernate.MappingException: Could not compile the mapping document: NHibernate.Test.BulkManipulation.SimpleClass.hbm.xml ---> NHibernate.DuplicateMappingException: Duplicate class/entity mapping NHibernate.Test.BulkManipulation.SimpleClass etc.) > Query with || operator and navigations (many-to-one) creates wrong joins > ------------------------------------------------------------------------ > > Key: NH-2583 > URL: http://216.121.112.228/browse/NH-2583 > Project: NHibernate > Issue Type: Bug > Components: Linq Provider > Affects Versions: 3.1.0 > Reporter: Harald M. Müller > Assignee: Patrick Earl > Priority: Critical > Attachments: JoinOptimizationForPureOuterJoinSemantics.txt, LogicalOperatorsInNHibernateLinq.txt, NH-2583a.diff, NH-2583b.diff, NH-2583c.diff, NH-2583d.diff, NH-2583e.diff, NH-2583f.diff, NH-2583g.diff, NH2583.7z, NHib3.0.0Or.zip > > > The following query > var result = session.Query<MyBO>() > .Where(bo => > (bo.BO1 != null && bo.BO1.I2 == 101) || > (bo.BO2 != null && bo.BO2.J2 == 203) > ) > ; > result.ToList(); > creates the following SQL on SQL Server 2008 (with .Net 4.0, MsSql2008Dialect): > exec sp_executesql N'select mybo0_.Id as Id0_, mybo0_.Name as Name0_, mybo0_.BO1Key as BO3_0_, mybo0_.OtherBO1Key as OtherBO4_0_, mybo0_.BO2Key as BO5_0_ from MyBO mybo0_, MyRef1 myref1x1_, MyRef2 myref2x2_ where mybo0_.BO1Key=myref1x1_.Id and mybo0_.BO2Key=myref2x2_.Id and ((mybo0_.BO1Key is not null) and myref1x1_.I2=@p0 or (mybo0_.BO2Key is not null) and myref2x2_.J2=@p1)',N'@p0 int,@p1 int',@p0=101,@p1=203 > or, formatted: > SELECT mybo0_.id AS id0_, > mybo0_.name AS name0_, > mybo0_.bo1key AS bo3_0_, > mybo0_.otherbo1key AS otherbo4_0_, > mybo0_.bo2key AS bo5_0_ > FROM mybo mybo0_, > myref1 myref1x1_, > myref2 myref2x2_ > WHERE mybo0_.bo1key = myref1x1_.id -- inner (table) join > AND mybo0_.bo2key = myref2x2_.id -- also inner (table) join > AND ( ( mybo0_.bo1key IS NOT NULL ) > AND myref1x1_.i2 = @p0 > OR ( mybo0_.bo2key IS NOT NULL ) > AND myref2x2_.j2 = @p1 ) > This is wrong if the reference to ref1 or ref2 is null. The attachment contains a small project that shows the problem. > AFAIK, the problem has been always present when using HQL navigations (a.b.c....); it is - somewhat implicitly - documented in seciotn 13.7.: > Compound path expressions make the where clause extremely powerful. Consider: > from Eg.Cat cat where cat.Mate.Name is not null > This query translates to an SQL query with a table (inner) join. > In HQL, one can claim that this is "a feature" (and the workaround is to use manual JOINs). With Linq, this is no longer possible - the semantics of the || operator should be correctly implemented, shouldn't it? Therefore, I dared to mark this bug as "Critical". > (... or - please - show me that I'm wrong and that || + navigation work as expected!). > Remark: In our project, which started with NHib 0.99 six years ago, we(I) wrote a complete expression framework akin to Linq (but only with conditions, not with expressions). When we found this problem, I rewrote the HQL builder so that it then created (and still creates) correct INNER or OUTER JOINs, depending on the expression tree (one has to consider Is-Null/Is-Not-Null operators and Not nodes above these, as far as I remember ... I'd have to look into our code). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |