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: Fabio M. (JIRA) <nh...@gm...> - 2011-05-16 13:05:41
|
[ http://216.121.112.228/browse/NH-2706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fabio Maulo updated NH-2706:
----------------------------
Priority: Major (was: Critical)
> subselect in LINQ query with Contains clause produces wrong SQL
> ---------------------------------------------------------------
>
> Key: NH-2706
> URL: http://216.121.112.228/browse/NH-2706
> Project: NHibernate
> Issue Type: Bug
> Components: Linq Provider
> Affects Versions: 3.1.0
> Reporter: Krzysztof Koźmic
> Priority: Major
>
> I was trying to execute the following query
> return (from foo in _session.Query<Foo>()
> where (from personBar in _session.Query<PersonBars>()
> where personBar.Person.Id == _personId
> select personBar.Bar).Contains(foo.Bar)
> orderby foo.FooNumber
> select new SomeProjection(
> foo.Id,
> foo.A,
> foo.B,
> foo.Bar.Id,
> foo.Bar.Description)).ToList();
> basically the goal was to get all Foos with Bar that given user of the app has Bar for too.
> now the part of the SQL generated that has a bug in it looks kind of like this (sorry for obscuring it):
> where some clauses
> and (exists (select bar_.ID
> from PERSON_BAR pb
> joins to bar
> where some other clauses here
> and pb.ID = foo0_.BAR_ID))
> Notice the last line which should say
> pb.BAR_ID = foo0.BAR_ID
> that's the bug.
> Hope that helps.
--
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: Christian A. (JIRA) <nh...@gm...> - 2011-05-16 12:15:47
|
Selecting into anonymous class generates invalid SQL
----------------------------------------------------
Key: NH-2707
URL: http://216.121.112.228/browse/NH-2707
Project: NHibernate
Issue Type: Bug
Components: Linq Provider
Affects Versions: 3.1.0
Reporter: Christian Axelsson
Priority: Major
Attachments: Models.zip
Tested on trunk and 3.1.0.
The following code:
var persons = from p in session.Query<Person>()
select new
{
p.Id,
p.Bookings
};
generates the following broken SQL (note the second column):
select person0_.ID as col_0_0_, . as col_1_0_, bookings1_.ID as ID1_, bookings1_.StartTime as StartTime1_, bookings1_.EndTime as EndTime1_ from dbo.Person person0_ inner join dbo.Booking bookings1_ on person0_.ID=bookings1_.PersonId
The person and booking classes are both trivial. A zip file containing the classes and their configuration is attached.
Tested on 3.1.0GA and trunk revision 5828. Provider used is MsSql2008Dialect.
--
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: Boyan T. (JIRA) <nh...@gm...> - 2011-05-16 06:22:47
|
[ http://216.121.112.228/browse/NH-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21081#action_21081 ]
Boyan Trushev commented on NH-2704:
-----------------------------------
Hi Fabio,
Thanks for the quick reply!
>NH have to hit the DB to know the value of the property holding the relation, hitting it he can initialize the object.
Why should NH hit the DB to know the value of the property? Couldn't this be done on accessing of the "lazy" property? The object containing the property is a proxy and it could check that the property is still not initialized and then hit the DB. That's exactly what I achieved with the patch I proposed in my previous comment. Have you had a look at it?
>In practice the one-to-one through FK is not a real one-to-one and it can be transformed to a one-to-many easily. The real one-to-one is through PK.
In our current project we use POCOs and for one-to-one relation there is a single property to hold the relation, it cannot be easily transformed to one-to-many as for one-to-many we will need a list rather than just a property - which is unacceptable in our case.
> Bidirectional one-to-one relation through FK (using property-ref) proxiable
> ---------------------------------------------------------------------------
>
> Key: NH-2704
> URL: http://216.121.112.228/browse/NH-2704
> Project: NHibernate
> Issue Type: Improvement
> Components: Core
> Affects Versions: 3.2.0Alpha3
> Reporter: Boyan Trushev
> Priority: Minor
> Attachments: NH2704.patch, NH2704_fix.patch
>
>
> Hi,
> In our project we use one-to-one relations that are not referencing same primary key, instead property-ref is used to specify the referenced property. In this case however we have noticed that lazy="proxy" doesn't work as expected - the "lazy" objects are eagerly loaded on loading of the parent objec
--
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: Krzysztof K. (J. <nh...@gm...> - 2011-05-16 03:28:45
|
[ http://216.121.112.228/browse/NH-2706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21080#action_21080 ]
Krzysztof Koźmic commented on NH-2706:
--------------------------------------
I think I found a workaround for now.
It seems to be working properly if I change the subselect to:
where (from personBar in _session.Query<PersonBars>()
where personBar.Person.Id == _personId
select personBar).Any(pb => pb.Bar == foo.Bar)
> subselect in LINQ query with Contains clause produces wrong SQL
> ---------------------------------------------------------------
>
> Key: NH-2706
> URL: http://216.121.112.228/browse/NH-2706
> Project: NHibernate
> Issue Type: Bug
> Components: Linq Provider
> Affects Versions: 3.1.0
> Reporter: Krzysztof Koźmic
> Priority: Critical
>
> I was trying to execute the following query
> return (from foo in _session.Query<Foo>()
> where (from personBar in _session.Query<PersonBars>()
> where personBar.Person.Id == _personId
> select personBar.Bar).Contains(foo.Bar)
> orderby foo.FooNumber
> select new SomeProjection(
> foo.Id,
> foo.A,
> foo.B,
> foo.Bar.Id,
> foo.Bar.Description)).ToList();
> basically the goal was to get all Foos with Bar that given user of the app has Bar for too.
> now the part of the SQL generated that has a bug in it looks kind of like this (sorry for obscuring it):
> where some clauses
> and (exists (select bar_.ID
> from PERSON_BAR pb
> joins to bar
> where some other clauses here
> and pb.ID = foo0_.BAR_ID))
> Notice the last line which should say
> pb.BAR_ID = foo0.BAR_ID
> that's the bug.
> Hope that helps.
--
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: Krzysztof K. (J. <nh...@gm...> - 2011-05-16 02:32:47
|
subselect in LINQ query with Contains clause produces wrong SQL
---------------------------------------------------------------
Key: NH-2706
URL: http://216.121.112.228/browse/NH-2706
Project: NHibernate
Issue Type: Bug
Components: Linq Provider
Affects Versions: 3.1.0
Reporter: Krzysztof Koźmic
Priority: Critical
I was trying to execute the following query
return (from foo in _session.Query<Foo>()
where (from personBar in _session.Query<PersonBars>()
where personBar.Person.Id == _personId
select personBar.Bar).Contains(foo.Bar)
orderby foo.FooNumber
select new SomeProjection(
foo.Id,
foo.A,
foo.B,
foo.Bar.Id,
foo.Bar.Description)).ToList();
basically the goal was to get all Foos with Bar that given user of the app has Bar for too.
now the part of the SQL generated that has a bug in it looks kind of like this (sorry for obscuring it):
where some clauses
and (exists (select bar_.ID
from PERSON_BAR pb
joins to bar
where some other clauses here
and pb.ID = foo0_.BAR_ID))
Notice the last line which should say
pb.BAR_ID = foo0.BAR_ID
that's the bug.
Hope that helps.
--
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: Andrei A. (JIRA) <nh...@gm...> - 2011-05-14 13:32:42
|
[ http://216.121.112.228/browse/NH-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21078#action_21078 ]
Andrei Alecu commented on NH-2705:
----------------------------------
I just noticed that I forgot to include the .csproj additions in the patch, so make sure to include the NHSpecificTest\NH2705 folder in the project after applying.
> Linq/Hql/Criteria Fetch on class hierarchy generates invalid SQL when derivees mix component and many-to-one mappings
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: NH-2705
> URL: http://216.121.112.228/browse/NH-2705
> Project: NHibernate
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.1.0
> Reporter: Andrei Alecu
> Priority: Major
> Attachments: nh2705 test.patch
>
>
> Consider the following scenario:
> public class ItemBase
> {
> public virtual int Id { get; set; }
> public virtual SubItemBase SubItem { get; set; }
> }
> public class ItemWithComponentSubItem:ItemBase { }
>
> public class ItemWithManyToOneSubItem:ItemBase { }
> ItemWithComponentSubItem defines in its mapping that SubItem is a component of SubItemComponent type (which derives from SubItemBase)
> ItemWithManyToOneSubItem defines in its mapping that SubItem is a many-to-one of SubItemEntity type (again, derives from SubItemBase)
> Running the following query with fetch results in invalid SQL being executed:
> from ItemBase i left join fetch i.SubItem
> Removing the fetch makes it work properly.
> from ItemBase i
> Also, this works:
> from ItemWithManyToOneSubItem i left join fetch i.SubItem
> But this doesn't:
> from ItemWithComponentSubItem i left join fetch i.SubItem (one would argue there's nothing to fetch here, but instead of throwing an exception, the fetch instruction should just be ignored and maybe a warning logged, it would allow for much better reuse of code)
> I will attach a unit test that demonstrates this bug, and also a related one at NH-2615.
> I believe the correct behavior here is to allow fetch on components, and simply ignore it rather than throwing an 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: Andrei A. (JIRA) <nh...@gm...> - 2011-05-14 13:28:44
|
[ http://216.121.112.228/browse/NH-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21077#action_21077 ]
Andrei Alecu commented on NH-2615:
----------------------------------
I have submitted a related issue at NH-2705 that contains a test which demonstrates this here bug as well.
I think NH-2615 should also be escalated from trivial to major.
> Linq Fetch cannot traverse through components
> ---------------------------------------------
>
> Key: NH-2615
> URL: http://216.121.112.228/browse/NH-2615
> Project: NHibernate
> Issue Type: Bug
> Components: Linq Provider
> Affects Versions: 3.0.0.GA
> Reporter: Jerome Haltom
>
> Subject seems to say it all. Gets an exception inside NH saying that the join is incorrect.
--
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: Andrei A. (JIRA) <nh...@gm...> - 2011-05-14 13:26:41
|
[ http://216.121.112.228/browse/NH-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21076#action_21076 ]
Andrei Alecu commented on NH-2701:
----------------------------------
Actually, I think this should be major, not trivial. Can't work around it while maintaining full function. :)
> Cannot use Linq Skip() in conjunction with FetchMany and ToFuture
> -----------------------------------------------------------------
>
> Key: NH-2701
> URL: http://216.121.112.228/browse/NH-2701
> Project: NHibernate
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.2.0Alpha3
> Reporter: Andrei Alecu
> Attachments: nh2701 failing test.patch
>
>
> Using .Skip() in conjunction with a query that uses FetchMany/Fetch() and .ToFuture() results in the following error:
> System.ArgumentException : Object of type 'System.Collections.ArrayList' cannot be converted to type 'System.Collections.Generic.IEnumerable`1[System.Object]'.
> Failing unit test 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: Andrei A. (JIRA) <nh...@gm...> - 2011-05-14 13:24:39
|
[ http://216.121.112.228/browse/NH-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrei Alecu updated NH-2705:
-----------------------------
Attachment: nh2705 test.patch
Attached test that shows this bug.
Also see NH-2615 which is also demonstrated by this test.
> Linq/Hql/Criteria Fetch on class hierarchy generates invalid SQL when derivees mix component and many-to-one mappings
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: NH-2705
> URL: http://216.121.112.228/browse/NH-2705
> Project: NHibernate
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.1.0
> Reporter: Andrei Alecu
> Priority: Major
> Attachments: nh2705 test.patch
>
>
> Consider the following scenario:
> public class ItemBase
> {
> public virtual int Id { get; set; }
> public virtual SubItemBase SubItem { get; set; }
> }
> public class ItemWithComponentSubItem:ItemBase { }
>
> public class ItemWithManyToOneSubItem:ItemBase { }
> ItemWithComponentSubItem defines in its mapping that SubItem is a component of SubItemComponent type (which derives from SubItemBase)
> ItemWithManyToOneSubItem defines in its mapping that SubItem is a many-to-one of SubItemEntity type (again, derives from SubItemBase)
> Running the following query with fetch results in invalid SQL being executed:
> from ItemBase i left join fetch i.SubItem
> Removing the fetch makes it work properly.
> from ItemBase i
> Also, this works:
> from ItemWithManyToOneSubItem i left join fetch i.SubItem
> But this doesn't:
> from ItemWithComponentSubItem i left join fetch i.SubItem (one would argue there's nothing to fetch here, but instead of throwing an exception, the fetch instruction should just be ignored and maybe a warning logged, it would allow for much better reuse of code)
> I will attach a unit test that demonstrates this bug, and also a related one at NH-2615.
> I believe the correct behavior here is to allow fetch on components, and simply ignore it rather than throwing an 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: Andrei A. (JIRA) <nh...@gm...> - 2011-05-14 13:20:40
|
Linq/Hql/Criteria Fetch on class hierarchy generates invalid SQL when derivees mix component and many-to-one mappings
---------------------------------------------------------------------------------------------------------------------
Key: NH-2705
URL: http://216.121.112.228/browse/NH-2705
Project: NHibernate
Issue Type: Bug
Components: Core
Affects Versions: 3.1.0
Reporter: Andrei Alecu
Priority: Major
Consider the following scenario:
public class ItemBase
{
public virtual int Id { get; set; }
public virtual SubItemBase SubItem { get; set; }
}
public class ItemWithComponentSubItem:ItemBase { }
public class ItemWithManyToOneSubItem:ItemBase { }
ItemWithComponentSubItem defines in its mapping that SubItem is a component of SubItemComponent type (which derives from SubItemBase)
ItemWithManyToOneSubItem defines in its mapping that SubItem is a many-to-one of SubItemEntity type (again, derives from SubItemBase)
Running the following query with fetch results in invalid SQL being executed:
from ItemBase i left join fetch i.SubItem
Removing the fetch makes it work properly.
from ItemBase i
Also, this works:
from ItemWithManyToOneSubItem i left join fetch i.SubItem
But this doesn't:
from ItemWithComponentSubItem i left join fetch i.SubItem (one would argue there's nothing to fetch here, but instead of throwing an exception, the fetch instruction should just be ignored and maybe a warning logged, it would allow for much better reuse of code)
I will attach a unit test that demonstrates this bug, and also a related one at NH-2615.
I believe the correct behavior here is to allow fetch on components, and simply ignore it rather than throwing an 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: Andrei A. (JIRA) <nh...@gm...> - 2011-05-14 00:18:45
|
[ http://216.121.112.228/browse/NH-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21074#action_21074 ]
Andrei Alecu commented on NH-2615:
----------------------------------
Can't seem to do .Fetch(p=>p.Component.Entity) either, it says the expression is too complex.
With .Fetch(p=>p.Component).ThenFetch(p=>p.Entity), it says that the p.Component join is invalid.
I believe the proper solution to this would be to allow a call like:
.Fetch(p=>p.Component).ThenFetch(p=>p.Entity)
Because otherwise the consumer needs to know specific details about how the mapping is defined, and does not work well in polymorphism situations when several classes inherit the same base but are mapped differently (for example some many use components and some may have many to ones)
> Linq Fetch cannot traverse through components
> ---------------------------------------------
>
> Key: NH-2615
> URL: http://216.121.112.228/browse/NH-2615
> Project: NHibernate
> Issue Type: Bug
> Components: Linq Provider
> Affects Versions: 3.0.0.GA
> Reporter: Jerome Haltom
>
> Subject seems to say it all. Gets an exception inside NH saying that the join is incorrect.
--
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-13 16:12:01
|
[ http://216.121.112.228/browse/NH-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fabio Maulo updated NH-2704:
----------------------------
Issue Type: Improvement (was: Bug)
Summary: Bidirectional one-to-one relation through FK (using property-ref) proxiable (was: Lazy="proxy" does eager load on one-to-one relation using property-ref)
The current behavior is expected due to the relation to a property that is not the PK.
NH have to hit the DB to know the value of the property holding the relation, hitting it he can initialize the object.
In practice the one-to-one through FK is not a real one-to-one and it can be transformed to a one-to-many easily. The real one-to-one is through PK.
> Bidirectional one-to-one relation through FK (using property-ref) proxiable
> ---------------------------------------------------------------------------
>
> Key: NH-2704
> URL: http://216.121.112.228/browse/NH-2704
> Project: NHibernate
> Issue Type: Improvement
> Components: Core
> Affects Versions: 3.2.0Alpha3
> Reporter: Boyan Trushev
> Priority: Minor
> Attachments: NH2704.patch, NH2704_fix.patch
>
>
> Hi,
> In our project we use one-to-one relations that are not referencing same primary key, instead property-ref is used to specify the referenced property. In this case however we have noticed that lazy="proxy" doesn't work as expected - the "lazy" objects are eagerly loaded on loading of the parent objec
--
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: Roy J. (JIRA) <nh...@gm...> - 2011-05-13 15:15:06
|
[ http://216.121.112.228/browse/NH-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21072#action_21072 ]
Roy Jacobs commented on NH-2703:
--------------------------------
If the joins could somehow respect the order that is also generated by "rootCriteria.IterateSubcriteria()" that would help already, because then it would be possible to manually influence the order of joins because they would reflect the order by which the subcriteria were added.
> Using a "with" restriction in outer joins result in wrong SQL
> -------------------------------------------------------------
>
> Key: NH-2703
> URL: http://216.121.112.228/browse/NH-2703
> Project: NHibernate
> Issue Type: Bug
> Components: QueryOver
> Affects Versions: 3.2.0Beta1
> Reporter: Roy Jacobs
> Priority: Major
> Attachments: JoinTest.zip
>
>
> I have a Parent class that has two types of children: "Child" in a list called "Children" and "Other" in a list called "OtherChildren".
> If I do a QueryOver on Parent, and outer join both Child and Other tables then everything works.
> If I add a "With" on the "Child" join, linking it to "Other" (e.g. child.MyProp == other.OtherProp) then the SQL that is generated does not work in SQL Server 2008:
> SELECT child2_.MyProp as y0_
> FROM Parent this_
> left outer join Child child2_ on this_.Id=child2_.parent_id and ( child2_.MyProp = other1_.OtherProp )
> left outer join Other other1_ on this_.Id=other1_.parent_id
> The error message is:
> System.Data.SqlClient.SqlException : The multi-part identifier "other1_.OtherProp" could not be bound.
> This is because SQL Server expects "other1_" to be joined *BEFORE* "child2_". If I manually change the join order around in the SQL, it works.
> Reshuffling the order in which I perform the joins in C# does not help, the emitted SQL is always incorrect.
> I have attached a failing test that can be added to NHibernate.Test which demonstrates this problem.
--
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: Roy J. (JIRA) <nh...@gm...> - 2011-05-13 13:28:11
|
[ http://216.121.112.228/browse/NH-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21071#action_21071 ]
Roy Jacobs commented on NH-2703:
--------------------------------
I did some more research:
The problem is that "JoinWalker.WalkEntityAssociationTree" is adding joins in the order in which the associations are added in the mapping.
So in my above test-case, if I place the "OtherChildren" association above "Children" in the mapping for the "Parent" class, the test succeeds.
Is this by design, or should this still be fixed?
> Using a "with" restriction in outer joins result in wrong SQL
> -------------------------------------------------------------
>
> Key: NH-2703
> URL: http://216.121.112.228/browse/NH-2703
> Project: NHibernate
> Issue Type: Bug
> Components: QueryOver
> Affects Versions: 3.2.0Beta1
> Reporter: Roy Jacobs
> Priority: Major
> Attachments: JoinTest.zip
>
>
> I have a Parent class that has two types of children: "Child" in a list called "Children" and "Other" in a list called "OtherChildren".
> If I do a QueryOver on Parent, and outer join both Child and Other tables then everything works.
> If I add a "With" on the "Child" join, linking it to "Other" (e.g. child.MyProp == other.OtherProp) then the SQL that is generated does not work in SQL Server 2008:
> SELECT child2_.MyProp as y0_
> FROM Parent this_
> left outer join Child child2_ on this_.Id=child2_.parent_id and ( child2_.MyProp = other1_.OtherProp )
> left outer join Other other1_ on this_.Id=other1_.parent_id
> The error message is:
> System.Data.SqlClient.SqlException : The multi-part identifier "other1_.OtherProp" could not be bound.
> This is because SQL Server expects "other1_" to be joined *BEFORE* "child2_". If I manually change the join order around in the SQL, it works.
> Reshuffling the order in which I perform the joins in C# does not help, the emitted SQL is always incorrect.
> I have attached a failing test that can be added to NHibernate.Test which demonstrates this problem.
--
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: Boyan T. (JIRA) <nh...@gm...> - 2011-05-13 12:12:01
|
[ http://216.121.112.228/browse/NH-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boyan Trushev updated NH-2704:
------------------------------
Attachment: NH2704_fix.patch
It seems only changing of islazyProperty assignment in EntityMetamodel to include also the one-to-one properties with lazy="proxy" solves the problem. The patch contains the proposed solution.
> Lazy="proxy" does eager load on one-to-one relation using property-ref
> ----------------------------------------------------------------------
>
> Key: NH-2704
> URL: http://216.121.112.228/browse/NH-2704
> Project: NHibernate
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.2.0Alpha3
> Reporter: Boyan Trushev
> Priority: Minor
> Attachments: NH2704.patch, NH2704_fix.patch
>
>
> Hi,
> In our project we use one-to-one relations that are not referencing same primary key, instead property-ref is used to specify the referenced property. In this case however we have noticed that lazy="proxy" doesn't work as expected - the "lazy" objects are eagerly loaded on loading of the parent objec
--
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: Boyan T. (JIRA) <nh...@gm...> - 2011-05-13 11:54:00
|
[ http://216.121.112.228/browse/NH-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boyan Trushev updated NH-2704:
------------------------------
Attachment: NH2704.patch
a patch with a test case to demonstrate the issue
> Lazy="proxy" does eager load on one-to-one relation using property-ref
> ----------------------------------------------------------------------
>
> Key: NH-2704
> URL: http://216.121.112.228/browse/NH-2704
> Project: NHibernate
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.2.0Alpha3
> Reporter: Boyan Trushev
> Priority: Minor
> Attachments: NH2704.patch
>
>
> Hi,
> In our project we use one-to-one relations that are not referencing same primary key, instead property-ref is used to specify the referenced property. In this case however we have noticed that lazy="proxy" doesn't work as expected - the "lazy" objects are eagerly loaded on loading of the parent objec
--
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: Boyan T. (JIRA) <nh...@gm...> - 2011-05-13 11:13:00
|
Lazy="proxy" does eager load on one-to-one relation using property-ref
----------------------------------------------------------------------
Key: NH-2704
URL: http://216.121.112.228/browse/NH-2704
Project: NHibernate
Issue Type: Bug
Components: Core
Affects Versions: 3.2.0Alpha3
Reporter: Boyan Trushev
Priority: Minor
Hi,
In our project we use one-to-one relations that are not referencing same primary key, instead property-ref is used to specify the referenced property. In this case however we have noticed that lazy="proxy" doesn't work as expected - the "lazy" objects are eagerly loaded on loading of the parent objec
--
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: Roy J. (JIRA) <nh...@gm...> - 2011-05-13 08:56:04
|
[ http://216.121.112.228/browse/NH-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21068#action_21068 ]
Roy Jacobs commented on NH-2703:
--------------------------------
It seems related to the fact that JoinWalker.MergeOuterJoins doesn't correctly sort the outer joins, but due to my unfamiliarity with the internals I'm not completely sure.
> Using a "with" restriction in outer joins result in wrong SQL
> -------------------------------------------------------------
>
> Key: NH-2703
> URL: http://216.121.112.228/browse/NH-2703
> Project: NHibernate
> Issue Type: Bug
> Components: QueryOver
> Affects Versions: 3.2.0Beta1
> Reporter: Roy Jacobs
> Priority: Major
> Attachments: JoinTest.zip
>
>
> I have a Parent class that has two types of children: "Child" in a list called "Children" and "Other" in a list called "OtherChildren".
> If I do a QueryOver on Parent, and outer join both Child and Other tables then everything works.
> If I add a "With" on the "Child" join, linking it to "Other" (e.g. child.MyProp == other.OtherProp) then the SQL that is generated does not work in SQL Server 2008:
> SELECT child2_.MyProp as y0_
> FROM Parent this_
> left outer join Child child2_ on this_.Id=child2_.parent_id and ( child2_.MyProp = other1_.OtherProp )
> left outer join Other other1_ on this_.Id=other1_.parent_id
> The error message is:
> System.Data.SqlClient.SqlException : The multi-part identifier "other1_.OtherProp" could not be bound.
> This is because SQL Server expects "other1_" to be joined *BEFORE* "child2_". If I manually change the join order around in the SQL, it works.
> Reshuffling the order in which I perform the joins in C# does not help, the emitted SQL is always incorrect.
> I have attached a failing test that can be added to NHibernate.Test which demonstrates this problem.
--
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: Roy J. (JIRA) <nh...@gm...> - 2011-05-13 08:34:59
|
Using a "with" restriction in outer joins result in wrong SQL
-------------------------------------------------------------
Key: NH-2703
URL: http://216.121.112.228/browse/NH-2703
Project: NHibernate
Issue Type: Bug
Components: QueryOver
Affects Versions: 3.2.0Beta1
Reporter: Roy Jacobs
Priority: Major
Attachments: JoinTest.zip
I have a Parent class that has two types of children: "Child" in a list called "Children" and "Other" in a list called "OtherChildren".
If I do a QueryOver on Parent, and outer join both Child and Other tables then everything works.
If I add a "With" on the "Child" join, linking it to "Other" (e.g. child.MyProp == other.OtherProp) then the SQL that is generated does not work in SQL Server 2008:
SELECT child2_.MyProp as y0_
FROM Parent this_
left outer join Child child2_ on this_.Id=child2_.parent_id and ( child2_.MyProp = other1_.OtherProp )
left outer join Other other1_ on this_.Id=other1_.parent_id
The error message is:
System.Data.SqlClient.SqlException : The multi-part identifier "other1_.OtherProp" could not be bound.
This is because SQL Server expects "other1_" to be joined *BEFORE* "child2_". If I manually change the join order around in the SQL, it works.
Reshuffling the order in which I perform the joins in C# does not help, the emitted SQL is always incorrect.
I have attached a failing test that can be added to NHibernate.Test which demonstrates this problem.
--
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-05-12 20:35:01
|
[ http://216.121.112.228/browse/NH-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21067#action_21067 ]
Patrick Earl commented on NH-2702:
----------------------------------
Fabio mentioned there are already two tests on the trunk for this.
> Support HQL pagination with parameters
> --------------------------------------
>
> Key: NH-2702
> URL: http://216.121.112.228/browse/NH-2702
> Project: NHibernate
> Issue Type: Improvement
> Components: Core
> Affects Versions: 3.2.0Alpha3
> Reporter: Patrick Earl
> Assignee: Patrick Earl
>
--
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-05-12 20:24:59
|
Support HQL pagination with parameters
--------------------------------------
Key: NH-2702
URL: http://216.121.112.228/browse/NH-2702
Project: NHibernate
Issue Type: Improvement
Components: Core
Affects Versions: 3.2.0Alpha3
Reporter: Patrick Earl
Assignee: Patrick Earl
--
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-12 19:48:59
|
[ http://216.121.112.228/browse/NH-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fabio Maulo closed NH-2546.
---------------------------
Resolution: Won't Fix
You can use
Restrictions.Like("StringTypeWithLengthDefined", "[a-z][a-z][a-z]ian%", MatchMode.Exact, null)
to ensure that the field length will be ignored.
> MSSQL Like criteria doesn't work if expression length is more then column length
> --------------------------------------------------------------------------------
>
> Key: NH-2546
> URL: http://216.121.112.228/browse/NH-2546
> Project: NHibernate
> Issue Type: Bug
> Components: DataProviders / Dialects
> Affects Versions: 3.0.0.GA
> Reporter: Denis
> Priority: Minor
> Attachments: NH-2546.patch
>
>
> Consider the following situation:
> mapping file contains the following property
> <property name="PostalCode" column="postal_code" type="String(10)"
> not-null="true"/>
> When I apply the following restriction
> Restrictions.Like("PostalCode", "%9108[ -]MC%")
> it doesn't work as expected.
> Generated query looks like this:
> SELECT count(*) as y0_ FROM PostalCodes this_ WHERE this_.postal_code like @p0;@p0 = '%9108[ -]MC%' [Type: String (10)]
> Parameter value length ('%9108[ -]MC%') is 12 symbols and it is correct expression but the value is cutted to '%9108[ -]M' which is not correct.
--
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: Andrei A. (JIRA) <nh...@gm...> - 2011-05-12 18:54:52
|
Cannot use Linq Skip() in conjunction with FetchMany and ToFuture
-----------------------------------------------------------------
Key: NH-2701
URL: http://216.121.112.228/browse/NH-2701
Project: NHibernate
Issue Type: Bug
Components: Core
Affects Versions: 3.2.0Alpha3
Reporter: Andrei Alecu
Attachments: nh2701 failing test.patch
Using .Skip() in conjunction with a query that uses FetchMany/Fetch() and .ToFuture() results in the following error:
System.ArgumentException : Object of type 'System.Collections.ArrayList' cannot be converted to type 'System.Collections.Generic.IEnumerable`1[System.Object]'.
Failing unit test 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: Patrick E. (JIRA) <nh...@gm...> - 2011-05-12 18:52:56
|
[ http://216.121.112.228/browse/NH-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Earl reassigned NH-2700:
--------------------------------
Assignee: Patrick Earl
> SqlFunctionProjection does not honor parameter order
> ----------------------------------------------------
>
> Key: NH-2700
> URL: http://216.121.112.228/browse/NH-2700
> Project: NHibernate
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.1.0
> Reporter: Andrei Alecu
> Assignee: Patrick Earl
> Priority: Minor
> Attachments: nh2700 failing test.patch
>
>
> If you define a function in a custom dialect that does not have the parameters in order and use SqlFunctionProjection, the generated sql is wrong, and does not honor parameter order.
> For example:
> RegisterFunction(
> "AddDays",
> new SQLFunctionTemplate(
> NHibernateUtil.DateTime,
> "dateadd(day,?2,?1)"
>
> )
> );
> var proj = new SqlFunctionProjection("AddDays", NHibernateUtil.DateTime,
> new IProjection[]
> {
> Projections.Property<ModelClass>(p=>p.Date1),
> Projections.Property<ModelClass>(p=>p.Value1)
> });
> Generated SQL (buggy):
> SELECT dateadd(day,this_.Date1,this_.Value1)
> Expected SQL:
> SELECT dateadd(day,this_.Value1,this_.Date1)
> Using an HQL query honors parameter order properly
> I will attach a failing unit test.
--
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-12 18:49:05
|
[ http://216.121.112.228/browse/NH-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21065#action_21065 ]
Fabio Maulo commented on NH-2546:
---------------------------------
The patch is not acceptable because another parameter just to revert the behavior of a line in the injectable driver is completely unneeded.
You can configure your driver and disable what you need disabled.
> MSSQL Like criteria doesn't work if expression length is more then column length
> --------------------------------------------------------------------------------
>
> Key: NH-2546
> URL: http://216.121.112.228/browse/NH-2546
> Project: NHibernate
> Issue Type: Bug
> Components: DataProviders / Dialects
> Affects Versions: 3.0.0.GA
> Reporter: Denis
> Priority: Minor
> Attachments: NH-2546.patch
>
>
> Consider the following situation:
> mapping file contains the following property
> <property name="PostalCode" column="postal_code" type="String(10)"
> not-null="true"/>
> When I apply the following restriction
> Restrictions.Like("PostalCode", "%9108[ -]MC%")
> it doesn't work as expected.
> Generated query looks like this:
> SELECT count(*) as y0_ FROM PostalCodes this_ WHERE this_.postal_code like @p0;@p0 = '%9108[ -]MC%' [Type: String (10)]
> Parameter value length ('%9108[ -]MC%') is 12 symbols and it is correct expression but the value is cutted to '%9108[ -]M' which is not correct.
--
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.
