Menu
▾
▴
nhibernate-issues — Updates to JIRA issues are sent to this list
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(110) |
Nov
(296) |
Dec
(107) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(212) |
Feb
(263) |
Mar
(161) |
Apr
(183) |
May
(183) |
Jun
(75) |
Jul
(106) |
Aug
(88) |
Sep
(227) |
Oct
(143) |
Nov
(154) |
Dec
(53) |
| 2008 |
Jan
(77) |
Feb
|
Mar
|
Apr
(6) |
May
(103) |
Jun
(296) |
Jul
(54) |
Aug
|
Sep
(379) |
Oct
(283) |
Nov
(224) |
Dec
(214) |
| 2009 |
Jan
(129) |
Feb
(257) |
Mar
(136) |
Apr
(12) |
May
(329) |
Jun
(434) |
Jul
(375) |
Aug
(171) |
Sep
|
Oct
|
Nov
|
Dec
(54) |
| 2010 |
Jan
(198) |
Feb
(76) |
Mar
(3) |
Apr
(1) |
May
|
Jun
(62) |
Jul
(210) |
Aug
(447) |
Sep
(330) |
Oct
(257) |
Nov
(133) |
Dec
(453) |
| 2011 |
Jan
(240) |
Feb
(128) |
Mar
(442) |
Apr
(320) |
May
(428) |
Jun
(141) |
Jul
(13) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Marc G. (JIRA) <nh...@gm...> - 2011-05-02 08:28:47
|
Unnecessary proxy initialisation in CriteriaQueryTranslator
-----------------------------------------------------------
Key: NH-2685
URL: http://216.121.112.228/browse/NH-2685
Project: NHibernate
Issue Type: Bug
Components: Core
Affects Versions: 3.2.0Alpha2, 3.2.0Alpha1, 3.1.0
Reporter: Marc Gerritsen
Priority: Minor
Attachments: Unnecessary proxy initialisation in CriteriaQueryTranslator.patch
For the construction of a debug string the ToString method is called on a proxy.
This initializes the proxy unnecessary.
To make sure this does not happen anymore i wrapped the logger lines with if (logger.IsDebugEnabled).
I attached the patch I created to fix the bug.
--
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: Richard B. (JIRA) <nh...@gm...> - 2011-05-01 18:31:47
|
[ http://216.121.112.228/browse/NH-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Brown closed NH-2624.
-----------------------------
Resolution: Not an Issue
> MultiCriteria does not work with criteria created using JoinQueryOver
> ---------------------------------------------------------------------
>
> Key: NH-2624
> URL: http://216.121.112.228/browse/NH-2624
> Project: NHibernate
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.1.0
> Reporter: xelibrion
> Assignee: Richard Brown
> Priority: Minor
>
> I've got exception
> System.InvalidCastException: Unable to cast object of type 'Subcriteria' to type 'NHibernate.Impl.CriteriaImpl'.
> at NHibernate.Impl.MultiCriteriaImpl.CreateCriteriaLoaders() in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\MultiCriteriaImpl.cs:line 287
> at NHibernate.Impl.MultiCriteriaImpl.List() in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\MultiCriteriaImpl.cs:line 73
> in code
> var queryOver = Session.QueryOver<Post>()
> .Fetch(x => x.Author).Eager
> .Fetch(x => x.Blog).Eager
> .JoinQueryOver(x => x.SearchRequests)
> .Where(x => x.Id == context.SearchRequestId)
> .TransformUsing(Transformers.DistinctRootEntity)
> .Skip(context.PageIndex*pageSize)
> .Take(pageSize);
> Session.CreateMultiCriteria()
> .Add(queryOver.UnderlyingCriteria)
> .Add(queryOver.ToRowCountQuery().UnderlyingCriteria)
> .List();
> I've found workaround using JoinAlias
--
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: xelibrion (JIRA) <nh...@gm...> - 2011-05-01 15:06:55
|
[ http://216.121.112.228/browse/NH-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20988#action_20988 ]
xelibrion commented on NH-2624:
-------------------------------
Okay, thank you for this information
> MultiCriteria does not work with criteria created using JoinQueryOver
> ---------------------------------------------------------------------
>
> Key: NH-2624
> URL: http://216.121.112.228/browse/NH-2624
> Project: NHibernate
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.1.0
> Reporter: xelibrion
> Assignee: Richard Brown
> Priority: Minor
>
> I've got exception
> System.InvalidCastException: Unable to cast object of type 'Subcriteria' to type 'NHibernate.Impl.CriteriaImpl'.
> at NHibernate.Impl.MultiCriteriaImpl.CreateCriteriaLoaders() in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\MultiCriteriaImpl.cs:line 287
> at NHibernate.Impl.MultiCriteriaImpl.List() in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\MultiCriteriaImpl.cs:line 73
> in code
> var queryOver = Session.QueryOver<Post>()
> .Fetch(x => x.Author).Eager
> .Fetch(x => x.Blog).Eager
> .JoinQueryOver(x => x.SearchRequests)
> .Where(x => x.Id == context.SearchRequestId)
> .TransformUsing(Transformers.DistinctRootEntity)
> .Skip(context.PageIndex*pageSize)
> .Take(pageSize);
> Session.CreateMultiCriteria()
> .Add(queryOver.UnderlyingCriteria)
> .Add(queryOver.ToRowCountQuery().UnderlyingCriteria)
> .List();
> I've found workaround using JoinAlias
--
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-05-01 11:26:55
|
More simple way to add NamedQueries by-code
-------------------------------------------
Key: NH-2684
URL: http://216.121.112.228/browse/NH-2684
Project: NHibernate
Issue Type: Improvement
Components: Core
Affects Versions: 3.1.0
Reporter: Fabio Maulo
Even if possible since long time the addition of namedqueries by code implies an advanced knowledge by the user.
We should add a builder, through a mew method of the Configuration, to add a named-query assigning default values giving the ability, to the user, to specify only he really need.
--
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-05-01 11:06:51
|
[ http://216.121.112.228/browse/NH-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20987#action_20987 ]
Fabio Maulo commented on NH-2683:
---------------------------------
In the base Dialect you can find all common HQL-functions registered for all dialects.
> Add common dialect functions as extension methods for QueryOver
> ---------------------------------------------------------------
>
> Key: NH-2683
> URL: http://216.121.112.228/browse/NH-2683
> Project: NHibernate
> Issue Type: Improvement
> Components: QueryOver
> Affects Versions: 3.2.0Alpha2
> Reporter: Richard Brown
> Assignee: Richard Brown
> Priority: Minor
>
> Some of the common functions (that are registered in most, if not all Dialects) can be used in ICriteria using SQL-projections.
> Extensions methods can be added for these to allow queries along the lines of:
> s.QueryOver<Person>()
> .Where(p => p.BirthDate.Year() == 1970)
> .List()
> ... which can be translated to:
> .Where(Restrictions.Eq(Projections.SqlFunction("year", NHibernateUtil.DateTime, Projections.Property<Person>(p => p.BirthDate)), 1970))
> ... and in turn to:
> datepart(year, this_.BirthDate) = @p0;
--
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: Richard B. (JIRA) <nh...@gm...> - 2011-05-01 10:45:50
|
[ http://216.121.112.228/browse/NH-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20986#action_20986 ]
Richard Brown commented on NH-2683:
-----------------------------------
In addition, the documentation can be extended to include examples using the extension methods (both the new ones, and existing ones).
> Add common dialect functions as extension methods for QueryOver
> ---------------------------------------------------------------
>
> Key: NH-2683
> URL: http://216.121.112.228/browse/NH-2683
> Project: NHibernate
> Issue Type: Improvement
> Components: QueryOver
> Affects Versions: 3.2.0Alpha2
> Reporter: Richard Brown
> Assignee: Richard Brown
> Priority: Minor
>
> Some of the common functions (that are registered in most, if not all Dialects) can be used in ICriteria using SQL-projections.
> Extensions methods can be added for these to allow queries along the lines of:
> s.QueryOver<Person>()
> .Where(p => p.BirthDate.Year() == 1970)
> .List()
> ... which can be translated to:
> .Where(Restrictions.Eq(Projections.SqlFunction("year", NHibernateUtil.DateTime, Projections.Property<Person>(p => p.BirthDate)), 1970))
> ... and in turn to:
> datepart(year, this_.BirthDate) = @p0;
--
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: Richard B. (JIRA) <nh...@gm...> - 2011-05-01 10:43:47
|
Add common dialect functions as extension methods for QueryOver
---------------------------------------------------------------
Key: NH-2683
URL: http://216.121.112.228/browse/NH-2683
Project: NHibernate
Issue Type: Improvement
Components: QueryOver
Affects Versions: 3.2.0Alpha2
Reporter: Richard Brown
Assignee: Richard Brown
Priority: Minor
Some of the common functions (that are registered in most, if not all Dialects) can be used in ICriteria using SQL-projections.
Extensions methods can be added for these to allow queries along the lines of:
s.QueryOver<Person>()
.Where(p => p.BirthDate.Year() == 1970)
.List()
... which can be translated to:
.Where(Restrictions.Eq(Projections.SqlFunction("year", NHibernateUtil.DateTime, Projections.Property<Person>(p => p.BirthDate)), 1970))
... and in turn to:
datepart(year, this_.BirthDate) = @p0;
--
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-30 20:25:57
|
[ http://216.121.112.228/browse/NH-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20985#action_20985 ]
Fabio Maulo commented on NH-2583:
---------------------------------
FYI
about run-time: a possible cause can be the number of exceptions created but, IMO, we should prevent the creation of those case generating exceptions.
btw, Herald, don't worry about the time, now what is more important is find a solution.
Thanks for your collaboration and the effort you put in this issue.
> 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: AbstractMassTestingFixture.cs, Domain.cs, 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-30 15:22:13
|
[ http://216.121.112.228/browse/NH-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20984#action_20984 ]
Harald M. Müller commented on NH-2583:
--------------------------------------
> The difference storing less entities is not so big. Probably the problem is in another place.
Mhm. That would require more precise measurements. Maybe I find to time to fire up a dotTrace.
> btw, I would know the situation of this issue. Which is the pending task to close the issue ?
Patrick should also comment on this. As I see it:
a) We know a solution that creates only outer joins (2 ways: Use "Select...JoinDetector" instead of WhereJoinDetector; or comment out call to MakeInnerIfJoined in WhereJoinDetector). BUT: Neither Patrick nor me have tested this; and for ?? and ?: operators, there are not even test cases.
b) We know that the current solution, which DOES optimize to inner joins, is WRONG when there is a ?? (coalesce) or ?: in the query. I have written an analysis text that explains a quite fine-granular solution for ??, but ?: the analysis is still missing. So there is not yet a solution that works correctly for inner joins with these operators.
Patrick, as I understood him, would like to check in a solution along the lines of a), so that we *have* a solution for || - even if it does not optimize to inner joins even in simple cases.
> 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: AbstractMassTestingFixture.cs, Domain.cs, 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: Fabio M. (JIRA) <nh...@gm...> - 2011-04-30 14:21:48
|
[ http://216.121.112.228/browse/NH-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20983#action_20983 ]
Fabio Maulo commented on NH-2673:
---------------------------------
Can you create a test ?
Something smaller than 7.8MB following this link
http://nhforge.org/blogs/nhibernate/archive/2008/10/04/the-best-way-to-solve-nhibernate-bugs-submit-good-unit-test.aspx
Thanks
> Nhibernate 2nd level cache and Result transformer
> -------------------------------------------------
>
> Key: NH-2673
> URL: http://216.121.112.228/browse/NH-2673
> Project: NHibernate
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.2.0Alpha2
> Reporter: Josef Holan
> Priority: Minor
> Attachments: Caching.zip
>
>
> I have a big problem with 2nd level cache in NHibernate. Everything is working fine(Cache is running well) until I use
> .SetResultTransformer(new DistinctRootEntityResultTransformer())
> Example code:
> using (var session = SessionFactory.OpenSession())
> {
> Console.WriteLine("---> using query first time");
> var query = session
> .CreateQuery("from Blog b where b.Author = :author")
> .SetString("author", "Gabriel")
> .SetCacheable(true)
> .SetResultTransformer(new DistinctRootEntityResultTransformer())
> ;
> var list = query.List<Blog>();
> }
> Exception:
> NHibernate.PropertyAccessException: Exception occurred getter of Caching.Blog.Id
> v NHibernate.Properties.BasicPropertyAccessor.BasicGetter.Get(Object target) v d:\CSharp\NH\NH\nhibernate\src\NHibernate\Properties\BasicPropertyAccessor.cs: line 211
> v NHibernate.Tuple.Entity.AbstractEntityTuplizer.GetIdentifier(Object entity) v d:\CSharp\NH\NH\nhibernate\src\NHibernate\Tuple\Entity\AbstractEntityTuplizer.cs: line 139
> v NHibernate.Persister.Entity.AbstractEntityPersister.GetIdentifier(Object obj, EntityMode entityMode) v d:\CSharp\NH\NH\nhibernate\src\NHibernate\Persister\Entity\AbstractEntityPersister.cs: line 3883
> v NHibernate.Persister.Entity.AbstractEntityPersister.IsTransient(Object entity, ISessionImplementor session) v d:\CSharp\NH\NH\nhibernate\src\NHibernate\Persister\Entity\AbstractEntityPersister.cs: line 3669
> v NHibernate.Engine.ForeignKeys.IsTransient(String entityName, Object entity, Nullable`1 assumed, ISessionImplementor session) v ForeignKeys.cs: line 194
> v NHibernate.Engine.ForeignKeys.GetEntityIdentifierIfNotUnsaved(String entityName, Object entity, ISessionImplementor session) v ForeignKeys.cs: line 250
> v NHibernate.Type.ManyToOneType.Disassemble(Object value, ISessionImplementor session, Object owner) v ManyToOneType.cs: line 137
> v NHibernate.Cache.StandardQueryCache.Put(QueryKey key, ICacheAssembler[] returnTypes, IList result, Boolean isNaturalKeyLookup, ISessionImplementor session) v StandardQueryCache.cs: line 82
> v NHibernate.Loader.Loader.PutResultInQueryCache(ISessionImplementor session, QueryParameters queryParameters, IType[] resultTypes, IQueryCache queryCache, QueryKey key, IList result) v Loader.cs: line 1668
> v NHibernate.Loader.Loader.ListUsingQueryCache(ISessionImplementor session, QueryParameters queryParameters, ISet`1 querySpaces, IType[] resultTypes) v Loader.cs: line 1617
> v NHibernate.Loader.Loader.List(ISessionImplementor session, QueryParameters queryParameters, ISet`1 querySpaces, IType[] resultTypes) v Loader.cs: line 1591
> v NHibernate.Hql.Ast.ANTLR.Loader.QueryLoader.List(ISessionImplementor session, QueryParameters queryParameters) v QueryLoader.cs: line 300
> v NHibernate.Hql.Ast.ANTLR.QueryTranslatorImpl.List(ISessionImplementor session, QueryParameters queryParameters) v QueryTranslatorImpl.cs: line 111
> v NHibernate.Engine.Query.HQLQueryPlan.PerformList(QueryParameters queryParameters, ISessionImplementor session, IList results) v HQLQueryPlan.cs: line 105
> v NHibernate.Impl.SessionImpl.List(String query, QueryParameters queryParameters, IList results) v SessionImpl.cs: line 616
> v NHibernate.Impl.SessionImpl.List<T>(String query, QueryParameters parameters) v SessionImpl.cs: line 592
> v NHibernate.Impl.QueryImpl.List<T>() v QueryImpl.cs: line 94
> v UnitTests.when_having_blog_with_posts.trying_to_cache_a_complex_query() v Blog_Spec.cs: line 110
> Mapping:
> <?xml version="1.0" encoding="utf-8" ?>
> <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
> namespace="Caching"
> assembly="Caching">
> <class name="Blog">
> <cache usage="read-write"/>
> <id name="Id">
> <generator class="hilo"/>
> </id>
> <property name="Author"/>
> <property name="Name"/>
> <set name="Posts" cascade="all" lazy="true">
> <cache usage="read-write"/>
> <key column="BlogId"/>
> <one-to-many class="Post"/>
> </set>
> </class>
> <class name="Post">
> <cache usage="read-write"/>
> <id name="Id">
> <generator class="hilo"/>
> </id>
> <property name="Title"/>
> <property name="Body"/>
> </class>
> </hibernate-mapping>
> Classes:
> public class Blog
> {
> public virtual int Id { get; set; }
> public virtual string Author { get; set; }
> public virtual string Name { get; set; }
> public virtual ISet<Post> Posts { get; set; }
> public Blog()
> {
> Posts = new HashedSet<Post>();
> }
> }
> public class Post
> {
> public virtual int Id { get; private set; }
> public virtual string Title { get; set; }
> public virtual string Body { get; set; }
> }
> nhibernate.config:
> <property name="cache.provider_class">NHibernate.Cache.HashtableCacheProvider</property>
> <property name="cache.use_second_level_cache">true</property>
> <property name="cache.use_query_cache" >true</property>
> In summary: Cache and nhibernate running well until i use result transformer. To work i must disable transformer or 2nd level cache. It is not working together
> This is only example, i know that distinct in this situation is stupid.
--
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-30 14:10:52
|
[ http://216.121.112.228/browse/NH-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20982#action_20982 ]
Fabio Maulo commented on NH-2583:
---------------------------------
Herald,
The difference storing less entities is not so big.
Probably the problem is in another place.
btw, I would know the situation of this issue.
Which is the pending task to close the issue ?
> 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: AbstractMassTestingFixture.cs, Domain.cs, 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: Fabio M. (JIRA) <nh...@gm...> - 2011-04-29 23:08:37
|
[ http://216.121.112.228/browse/NH-2681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fabio Maulo updated NH-2681:
----------------------------
Priority: Trivial (was: Major)
Affects Version/s: (was: 3.2.0Alpha2)
(was: 3.2.0Alpha1)
> Question marks in column names are not escaped correctly
> --------------------------------------------------------
>
> Key: NH-2681
> URL: http://216.121.112.228/browse/NH-2681
> Project: NHibernate
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.1.0
> Reporter: Diego Mijelshon
>
> Given a mapping like this:
> <class name="Foo">
> ...
> <property name="IsBar" column="`Bar?`" />
> </class>
> The following HQL fails trying to replace the question mark with a parameter:
> from Foo
> This, however, works correctly:
> select IsBar from Foo
--
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-29 23:06:40
|
[ http://216.121.112.228/browse/NH-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fabio Maulo closed NH-2682.
---------------------------
Resolution: Won't Fix
NH make a clear difference between QueryCache and EntityCache.
GetAllSecondLevelCacheRegions works as explected.
> SessionFactoryImpl.GetAllSecondLevelCacheRegions() / IQueryCache Inconsistency
> ------------------------------------------------------------------------------
>
> Key: NH-2682
> URL: http://216.121.112.228/browse/NH-2682
> Project: NHibernate
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.0.0.GA
> Reporter: Dana Naideth
> Priority: Minor
>
> This method appears to return all *named* query caches, but does not return the *standard* query cache. For example:
> // standard query cache used here
> var x = session.CreateCriteria(typeof(User)).SetCacheable(true).List();
> // named query cache used here
> var y = session.CreateCriteria(typeof(User)).SetCacheable(true).SetCacheRegion("NamedCacheRegion")List();
> I realize that there property "SessionFactoryImpl.QueryCache" that provides access to the standard query cache, but it seems inconsistent to me that "SessionFactoryImpl.GetALLSecondLevelCacheRegions()" would return some, but not all of the query caches.
--
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-29 23:00:42
|
[ http://216.121.112.228/browse/NH-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fabio Maulo closed NH-2680.
---------------------------
Resolution: Won't Fix
> NH does not create proxies for components on query
> --------------------------------------------------
>
> Key: NH-2680
> URL: http://216.121.112.228/browse/NH-2680
> Project: NHibernate
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.2.0Alpha2
> Reporter: Lucian Bargaoanu
> Priority: Minor
> Attachments: NhConfiguration.cs
>
>
> I'm using uNhAddIns which always uses proxies, not simple types. The problem is that a LINQ query doesn't return proxies for components. You can workaround the problem using a custom component tuplizer (which seems way too difficult to setup in code). I believe that the root cause is in AbstractComponentTuplizer which calls the virtual method BuildInstantiator in its constructor. The PocoComponentTuplizer ovverides BuildInstantiator and tries to use the optimizer setup in its constructor that didn't have a chance to run yet. So it finds the optimizer null and so it returns the simple type, not a proxy. I've attached my workaround.
--
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: Dana N. (JIRA) <nh...@gm...> - 2011-04-28 22:02:59
|
SessionFactoryImpl.GetAllSecondLevelCacheRegions() / IQueryCache Inconsistency
------------------------------------------------------------------------------
Key: NH-2682
URL: http://216.121.112.228/browse/NH-2682
Project: NHibernate
Issue Type: Bug
Components: Core
Affects Versions: 3.0.0.GA
Reporter: Dana Naideth
Priority: Minor
This method appears to return all *named* query caches, but does not return the *standard* query cache. For example:
// standard query cache used here
var x = session.CreateCriteria(typeof(User)).SetCacheable(true).List();
// named query cache used here
var y = session.CreateCriteria(typeof(User)).SetCacheable(true).SetCacheRegion("NamedCacheRegion")List();
I realize that there property "SessionFactoryImpl.QueryCache" that provides access to the standard query cache, but it seems inconsistent to me that "SessionFactoryImpl.GetALLSecondLevelCacheRegions()" would return some, but not all of the query caches.
--
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: Diego M. (JIRA) <nh...@gm...> - 2011-04-28 13:16:09
|
Question marks in column names are not escaped correctly
--------------------------------------------------------
Key: NH-2681
URL: http://216.121.112.228/browse/NH-2681
Project: NHibernate
Issue Type: Bug
Components: Core
Affects Versions: 3.2.0Alpha2, 3.2.0Alpha1, 3.1.0
Reporter: Diego Mijelshon
Priority: Major
Given a mapping like this:
<class name="Foo">
...
<property name="IsBar" column="`Bar?`" />
</class>
The following HQL fails trying to replace the question mark with a parameter:
from Foo
This, however, works correctly:
select IsBar from Foo
--
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: Lucian B. (JIRA) <nh...@gm...> - 2011-04-28 08:24:56
|
NH does not create proxies for components on query
--------------------------------------------------
Key: NH-2680
URL: http://216.121.112.228/browse/NH-2680
Project: NHibernate
Issue Type: Bug
Components: Core
Affects Versions: 3.2.0Alpha2
Reporter: Lucian Bargaoanu
Priority: Minor
Attachments: NhConfiguration.cs
I'm using uNhAddIns which always uses proxies, not simple types. The problem is that a LINQ query doesn't return proxies for components. You can workaround the problem using a custom component tuplizer (which seems way too difficult to setup in code). I believe that the root cause is in AbstractComponentTuplizer which calls the virtual method BuildInstantiator in its constructor. The PocoComponentTuplizer ovverides BuildInstantiator and tries to use the optimizer setup in its constructor that didn't have a chance to run yet. So it finds the optimizer null and so it returns the simple type, not a proxy. I've attached my workaround.
--
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: Richard B. (JIRA) <nh...@gm...> - 2011-04-27 16:13:13
|
[ http://216.121.112.228/browse/NH-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20980#action_20980 ]
Richard Brown commented on NH-2624:
-----------------------------------
Ahh, my mistake. I think the syntax is:
Session.CreateMultiCriteria()
.Add(queryOver)
.Add<int>(queryOver.ToRowCountQuery())
.List();
(note the explicit type to be returned in the second query)
Also, you can do this with Futures:
var results = queryOver.Future();
var resultsCount = queryOver.ToRowCountQuery().FutureValue<int>().Value;
> MultiCriteria does not work with criteria created using JoinQueryOver
> ---------------------------------------------------------------------
>
> Key: NH-2624
> URL: http://216.121.112.228/browse/NH-2624
> Project: NHibernate
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.1.0
> Reporter: xelibrion
> Assignee: Richard Brown
> Priority: Minor
>
> I've got exception
> System.InvalidCastException: Unable to cast object of type 'Subcriteria' to type 'NHibernate.Impl.CriteriaImpl'.
> at NHibernate.Impl.MultiCriteriaImpl.CreateCriteriaLoaders() in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\MultiCriteriaImpl.cs:line 287
> at NHibernate.Impl.MultiCriteriaImpl.List() in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\MultiCriteriaImpl.cs:line 73
> in code
> var queryOver = Session.QueryOver<Post>()
> .Fetch(x => x.Author).Eager
> .Fetch(x => x.Blog).Eager
> .JoinQueryOver(x => x.SearchRequests)
> .Where(x => x.Id == context.SearchRequestId)
> .TransformUsing(Transformers.DistinctRootEntity)
> .Skip(context.PageIndex*pageSize)
> .Take(pageSize);
> Session.CreateMultiCriteria()
> .Add(queryOver.UnderlyingCriteria)
> .Add(queryOver.ToRowCountQuery().UnderlyingCriteria)
> .List();
> I've found workaround using JoinAlias
--
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: Richard B. (JIRA) <nh...@gm...> - 2011-04-27 15:23:59
|
[ http://216.121.112.228/browse/NH-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Brown reassigned NH-2662:
---------------------------------
Assignee: Richard Brown
> Casting a joined alias in QueryOver loses alias context and looks for property on QueryOver root
> ------------------------------------------------------------------------------------------------
>
> Key: NH-2662
> URL: http://216.121.112.228/browse/NH-2662
> Project: NHibernate
> Issue Type: Bug
> Components: QueryOver
> Affects Versions: 3.2.0Alpha2
> Reporter: Graeme Foster
> Assignee: Richard Brown
> Priority: Major
> Attachments: NH2662.zip
>
>
> If you QueryOver an entity, alias-join to a property on that entity which has an inheritance tree, and then attempt to project a property on a specific subclass of the entity, the property path loses the context of the alias and attempts to find it on the queryover root.
> Pseudo code:
> QueryOver<Customer>()
> .JoinAlias(c => c.Order, () => orderAlias)
> .SelectList(list => list.Select( () => ((SpecialOrder)orderAlias).SpecialReason);
> blows up.
> The equivalent in linq-nhibernate works OK which is why I think this is a bug.
> Query<Customer>().Select( c => new { SpecialReason = ((SpecialOrder)c.Order).SpecialReason } );
> Will attach issue zip in same format as NH Trunk issues.
> Graeme
--
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: xelibrion (JIRA) <nh...@gm...> - 2011-04-27 14:31:26
|
[ http://216.121.112.228/browse/NH-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20979#action_20979 ]
xelibrion commented on NH-2624:
-------------------------------
>Can you let me know if that helps?
Sure.
Overload with IQueryOver does not work for me, i've got
System.ArgumentException: The value "2" is not of type "BlogAnalysis.DomainModel.Entities.Post" and cannot be used in this generic collection.
Parameter name: value
but second option works fine
> MultiCriteria does not work with criteria created using JoinQueryOver
> ---------------------------------------------------------------------
>
> Key: NH-2624
> URL: http://216.121.112.228/browse/NH-2624
> Project: NHibernate
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.1.0
> Reporter: xelibrion
> Assignee: Richard Brown
> Priority: Minor
>
> I've got exception
> System.InvalidCastException: Unable to cast object of type 'Subcriteria' to type 'NHibernate.Impl.CriteriaImpl'.
> at NHibernate.Impl.MultiCriteriaImpl.CreateCriteriaLoaders() in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\MultiCriteriaImpl.cs:line 287
> at NHibernate.Impl.MultiCriteriaImpl.List() in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\MultiCriteriaImpl.cs:line 73
> in code
> var queryOver = Session.QueryOver<Post>()
> .Fetch(x => x.Author).Eager
> .Fetch(x => x.Blog).Eager
> .JoinQueryOver(x => x.SearchRequests)
> .Where(x => x.Id == context.SearchRequestId)
> .TransformUsing(Transformers.DistinctRootEntity)
> .Skip(context.PageIndex*pageSize)
> .Take(pageSize);
> Session.CreateMultiCriteria()
> .Add(queryOver.UnderlyingCriteria)
> .Add(queryOver.ToRowCountQuery().UnderlyingCriteria)
> .List();
> I've found workaround using JoinAlias
--
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: Richard B. (JIRA) <nh...@gm...> - 2011-04-27 14:13:10
|
[ http://216.121.112.228/browse/NH-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20978#action_20978 ]
Richard Brown commented on NH-2624:
-----------------------------------
Hi,
There is an overload on the IMultiCriteria that takes an IQueryOver, so I would expect the following to work:
Session.CreateMultiCriteria()
.Add(queryOver)
.Add(queryOver.ToRowCountQuery())
.List();
Alternatively, all that does behind the scenes is grab the 'root' criteria, so the following should also work:
Session.CreateMultiCriteria()
.Add(queryOver.RootCriteria) // not UnderlyingCriteria
.Add(queryOver.ToRowCountQuery().RootCriteria)
.List();
Can you let me know if that helps?
Cheers,
Richard
> MultiCriteria does not work with criteria created using JoinQueryOver
> ---------------------------------------------------------------------
>
> Key: NH-2624
> URL: http://216.121.112.228/browse/NH-2624
> Project: NHibernate
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.1.0
> Reporter: xelibrion
> Assignee: Richard Brown
> Priority: Minor
>
> I've got exception
> System.InvalidCastException: Unable to cast object of type 'Subcriteria' to type 'NHibernate.Impl.CriteriaImpl'.
> at NHibernate.Impl.MultiCriteriaImpl.CreateCriteriaLoaders() in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\MultiCriteriaImpl.cs:line 287
> at NHibernate.Impl.MultiCriteriaImpl.List() in d:\CSharp\NH\NH\nhibernate\src\NHibernate\Impl\MultiCriteriaImpl.cs:line 73
> in code
> var queryOver = Session.QueryOver<Post>()
> .Fetch(x => x.Author).Eager
> .Fetch(x => x.Blog).Eager
> .JoinQueryOver(x => x.SearchRequests)
> .Where(x => x.Id == context.SearchRequestId)
> .TransformUsing(Transformers.DistinctRootEntity)
> .Skip(context.PageIndex*pageSize)
> .Take(pageSize);
> Session.CreateMultiCriteria()
> .Add(queryOver.UnderlyingCriteria)
> .Add(queryOver.ToRowCountQuery().UnderlyingCriteria)
> .List();
> I've found workaround using JoinAlias
--
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-27 07:26:04
|
[ http://216.121.112.228/browse/NH-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Harald M. Müller updated NH-2648:
---------------------------------
Attachment: NH2648Testcase.zip
I have attached a new test case NH2648Testcase.zip with (a) cleaner code; (b) a successful and a failing query to show that the problem is the join inside the exists.
> 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.0Alpha2
> Reporter: Harald M. Müller
> Priority: Critical
> Attachments: ASTForSubqueryFrom.gif, FromElementsForSubqueryFrom.gif, HQL_MissingJoinInExists.zip, NH2648Testcase.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-26 21:13:28
|
[ http://216.121.112.228/browse/NH-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20976#action_20976 ]
Fabio Maulo commented on NH-2583:
---------------------------------
LOL!!! The Console.WriteLine was removed
> 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: AbstractMassTestingFixture.cs, Domain.cs, 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-26 20:30:25
|
[ 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: Domain.cs
AbstractMassTestingFixture.cs
The two files added last (AbstractMassTestingFixture and Domain) reduce the number of created objects in the tests from 60680 to 24262 for all NH-2583 tests. This is still a large number, but at least it's smaller ....
The tactics employed is not to create objects repeatedly:
* Earlier, both an assignment of "null" and "0" would lead to the same object graph if the respective property would only accept "0" (i.e., it was an int and not an int?).
* Now, an InvalidOperationException is thrown on the attempted assignment, which hinders the creator to save the obejcts to the test database.
> 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: AbstractMassTestingFixture.cs, Domain.cs, 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: Fabio M. (JIRA) <nh...@gm...> - 2011-04-26 19:24:24
|
[ http://216.121.112.228/browse/NH-2679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fabio Maulo updated NH-2679:
----------------------------
Issue Type: Improvement (was: Bug)
> The UnionResultOperator result operator is not current supported
> ----------------------------------------------------------------
>
> Key: NH-2679
> URL: http://216.121.112.228/browse/NH-2679
> Project: NHibernate
> Issue Type: Improvement
> Components: Linq Provider
> Affects Versions: 3.1.0
> Reporter: Michael Teper
> Priority: Major
>
> var result1 = from foo in ISession.Query<Foo>
> where ...
> select foo.Bar;
> var result2 = from foo in ISession.Query<Foo>
> where ...
> select foo.Bar;
> var result3 = result1.Union(result2);
--
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
|
35 messages has been excluded from this view by a project administrator.
