nhibernate-issues — Updates to JIRA issues are sent to this list

[nhibernate-issues] [NHJIRA] Updated: (NH-2683) Add common dialect functions as extension methods for QueryOver

[Vahid N. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vahid Nasiri updated NH-2683:
-----------------------------

    Attachment: ProjectionsExtensions.zip

A new patch has been attached.

> 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
>         Attachments: ProjectionsExtensions.zip, QueryOverSqlFuncsExts.zip
>
>
> 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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2683) Add common dialect functions as extension methods for QueryOver

[Vahid N. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21101#action_21101 ] 

Vahid Nasiri commented on NH-2683:
----------------------------------

Hi Richard,
Yes, this new syntax is much better, because in my not very recent sources of NH, I hadn't "Expression<Func<T>>" in RegisterCustomProjection. It was just "bool" not "T"! So I had to invent that fluent syntax to return just bool. I'll rewrite everything! 
Thanks for the comments.


> 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
>         Attachments: QueryOverSqlFuncsExts.zip
>
>
> 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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2696) ReadOnly without lazyInitializer.IsReadOnlySettingAvailable in TwoPhaseLoad.cs

[Phillip C. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21100#action_21100 ] 

Phillip Conrad commented on NH-2696:
------------------------------------

I have made a unit-test for this scenario. But at the moment i can't reproduce the error.
If I have more time again, I will try to extract the error from our business application.

> ReadOnly without lazyInitializer.IsReadOnlySettingAvailable in TwoPhaseLoad.cs
> ------------------------------------------------------------------------------
>
>                 Key: NH-2696
>                 URL: http://216.121.112.228/browse/NH-2696
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 3.1.0, 3.2.0Alpha1, 3.2.0Alpha2
>            Reporter: Phillip Conrad
>            Priority: Minor
>         Attachments: exception.txt, nh-bug-scenario.png, TwoPhaseLoad.fix.cs
>
>
> Bug-Scenario:
> - 2 component-types of the same datatype in one union-subclass
> - lazy="true" in uni-subclass definition
> - proxyfactory.factory_class: NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle
> - NH 3.1.0GA
> The "((INHibernateProxy) proxy).HibernateLazyInitializer.ReadOnly"-Property throw a exception, because
> the session in the lazyInitializer is null.
> Exception: "Proxy is detached (i.e, session is null). The read-only/modifiable setting is only accessible when the proxy is associated with an open session."
> A similar bug was reported here: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5871
> The same fix will remove this error in nhibernate. 
> The solution is to use "lazyInitializer.IsReadOnlySettingAvailable".
> I have posted the same bug here: http://groups.google.com/group/nhusers/browse_thread/thread/d223e79b81a7be41

-- 
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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2683) Add common dialect functions as extension methods for QueryOver

[Richard B. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21099#action_21099 ] 

Richard Brown commented on NH-2683:
-----------------------------------

Hi Vahid,

I've already started down the road of implementing custom extensions (there's only 1 just now, the rest will follow).  You can see an example of its usage at the bottom of the code here:  http://nhibernate.svn.sourceforge.net/viewvc/nhibernate/trunk/nhibernate/src/NHibernate.Test/Criteria/Lambda/RestrictionsFixture.cs?revision=5829&view=markup

Hopefully you'll agree it's a nice syntax.

For reference, patches should include NH test cases that are self-contained (yours appear to require some kind of data setup?).  In addition, the QueryOver tests mostly use unit-tests that compare the output to ICriteria (rather than slower integration tests) - and only use integration tests where necessary.

Cheers,
    Richard


> 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
>         Attachments: QueryOverSqlFuncsExts.zip
>
>
> 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

        

[nhibernate-issues] [NHJIRA] Updated: (NH-2683) Add common dialect functions as extension methods for QueryOver

[Vahid N. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vahid Nasiri updated NH-2683:
-----------------------------

    Attachment: QueryOverSqlFuncsExts.zip

Hi,
Regarding NH-2683, I've created an extension method (attached) which accepts a fluent based "SqlFunction().Restriction()" form methods as its argument. Please let me know what do you think about it.

BR


> 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
>         Attachments: QueryOverSqlFuncsExts.zip
>
>
> 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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2705) Linq/Hql/Criteria Fetch on class hierarchy generates invalid SQL when derivees mix component and many-to-one mappings

[Andrei A. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21097#action_21097 ] 

Andrei Alecu commented on NH-2705:
----------------------------------

Thanks Fabio.

I understand the considerations, but I think I took the necessary precautions (only having Id in the many-to-one subclass, separate subclasses, etc), and it seems to work in our application otherwise, except for this fetch issue.

I'm mostly just interested in NHibernate being able to ignore the Fetch on component, so I can have repository methods that can take either subclass and not throw an invalid join exception.

Less concerned about the invalid SQL right now.

> 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: Improvement
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Andrei Alecu
>            Priority: Minor
>         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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2705) Linq/Hql/Criteria Fetch on class hierarchy generates invalid SQL when derivees mix component and many-to-one mappings

[Fabio M. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21096#action_21096 ] 

Fabio Maulo commented on NH-2705:
---------------------------------

Andrei,
for this test there is no problem but, as advise, don't try to put a component with an entity in the same hierarchy; the case is not supported by neither ObjectRelationalMapping nor NHibernate and is not supposed to work always.

> 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: Improvement
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Andrei Alecu
>            Priority: Minor
>         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

        

[nhibernate-issues] [NHJIRA] Resolved: (NH-2698) Proxying fails for methods with generic type constraints

[Richard B. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Brown resolved NH-2698.
-------------------------------

       Resolution: Fixed
    Fix Version/s: 3.2.0Beta1

> Proxying fails for methods with generic type constraints
> --------------------------------------------------------
>
>                 Key: NH-2698
>                 URL: http://216.121.112.228/browse/NH-2698
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: ByteCode providers
>    Affects Versions: 3.2.0Alpha3
>            Reporter: cremor
>             Fix For: 3.2.0Beta1
>
>         Attachments: NH2698 Test.zip
>
>
> I just tried to implement the As<T>() method described in this blog post:
> http://sessionfactory.blogspot.com/2010/08/hacking-lazy-loaded-inheritance.html
> But it seems like the dynamic proxy factory has problems creating proxies for methods with generic type constraints. Generic methods without constraints work perfectly, but I need a constraint in that method for the "as" operator.

-- 
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

        

[nhibernate-issues] [NHJIRA] Reopened: (NH-2698) Proxying fails for methods with generic type constraints

[Richard B. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Brown reopened NH-2698:
-------------------------------


> Proxying fails for methods with generic type constraints
> --------------------------------------------------------
>
>                 Key: NH-2698
>                 URL: http://216.121.112.228/browse/NH-2698
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: ByteCode providers
>    Affects Versions: 3.2.0Alpha3
>            Reporter: cremor
>         Attachments: NH2698 Test.zip
>
>
> I just tried to implement the As<T>() method described in this blog post:
> http://sessionfactory.blogspot.com/2010/08/hacking-lazy-loaded-inheritance.html
> But it seems like the dynamic proxy factory has problems creating proxies for methods with generic type constraints. Generic methods without constraints work perfectly, but I need a constraint in that method for the "as" operator.

-- 
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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2698) Proxying fails for methods with generic type constraints

[cremor (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21095#action_21095 ] 

cremor commented on NH-2698:
----------------------------

Seems like this was fixed with r5816, thanks!
I think the issue should be changed to "fixed in 3.2.0.Beta1" so it appears in the changelog.

> Proxying fails for methods with generic type constraints
> --------------------------------------------------------
>
>                 Key: NH-2698
>                 URL: http://216.121.112.228/browse/NH-2698
>             Project:  NHibernate
>          Issue Type: Bug
>          Components: ByteCode providers
>    Affects Versions: 3.2.0Alpha3
>            Reporter: cremor
>         Attachments: NH2698 Test.zip
>
>
> I just tried to implement the As<T>() method described in this blog post:
> http://sessionfactory.blogspot.com/2010/08/hacking-lazy-loaded-inheritance.html
> But it seems like the dynamic proxy factory has problems creating proxies for methods with generic type constraints. Generic methods without constraints work perfectly, but I need a constraint in that method for the "as" operator.

-- 
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

        

[nhibernate-issues] [NHJIRA] Updated: (NH-2615) Linq Fetch cannot traverse through components

[Fabio M. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fabio Maulo updated NH-2615:
----------------------------

    Issue Type: Bug  (was: Improvement)

Related to what we will do with NH-2705, ignoring the "Invalid join", we should allow two possible syntax:
1)s.Query<ItemBase>().Fetch(p => p.SubItem.Details).ToList()
2)s.Query<ItemBase>().Fetch(p => p.SubItem).ThenFetch(p => p.Details).ToList()

1) in practice the same behavior you can already write a HQL
2) if we ignore the "Invalid join" we may allow the concatenation of the property path between Fetch and ThenFetch when the property of Fetch is a component.

between this and the related issue we have 4 or more issues of different type/priority (a nice pot-pourri...btw understandable in this situation).

> 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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2705) Linq/Hql/Criteria Fetch on class hierarchy generates invalid SQL when derivees mix component and many-to-one mappings

[Fabio M. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21093#action_21093 ] 

Fabio Maulo commented on NH-2705:
---------------------------------

That is right.
I'll comment on that issue.

> 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: Improvement
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Andrei Alecu
>            Priority: Minor
>         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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2705) Linq/Hql/Criteria Fetch on class hierarchy generates invalid SQL when derivees mix component and many-to-one mappings

[Andrei A. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21092#action_21092 ] 

Andrei Alecu commented on NH-2705:
----------------------------------

Alright, then I guess the bug is that there's not a clear exception being thrown if this is not a supported scenario. :)

I believe we should get an exception instead of executing invalid SQL.

Regarding not being able to fetch through components, I believe that's also a bug, your comment:

  The LINQ 
session.Query<T>().Fetch(p => p.SubItem.Details).Where(p => p.SubItem.Name == name).ToList(); 
is NH-2615

Results in the following error:

  A fetch request must be a simple member access expression of the kind o => o.Related; 'p.SubItem.Details' is too complex.\r\nParameter name: relatedObjectSelector

So, there's no way to fetch through components currently.

> 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: Improvement
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Andrei Alecu
>            Priority: Minor
>         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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2703) Using a "with" restriction in outer joins result in wrong SQL

[Roy J. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21091#action_21091 ] 

Roy Jacobs commented on NH-2703:
--------------------------------

I have attached a patch that solves the issue by sorting the associations with a 'with' clause based on dependencies. I took the topology sorting code from a blog (as indicated in the code).

The analysis of which aliases are used in the 'with' clause uses a regex to figure out the names of the aliases. I realize there must be a cleaner way to do this, but for the life of me I couldn't extract the aliases without it becoming a huge complicated mess (e.g. parsing PropertyExpressions and Subcriteria and so on).

As it is, this solution seems to work and all unit tests pass.

> 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, nh2703-fix.patch
>
>
> 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

        

[nhibernate-issues] [NHJIRA] Updated: (NH-2703) Using a "with" restriction in outer joins result in wrong SQL

[Roy J. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Roy Jacobs updated NH-2703:
---------------------------

    Attachment: nh2703-fix.patch

Sorting associations based on dependencies

> 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, nh2703-fix.patch
>
>
> 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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2705) Linq/Hql/Criteria Fetch on class hierarchy generates invalid SQL when derivees mix component and many-to-one mappings

[Fabio M. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21089#action_21089 ] 

Fabio Maulo commented on NH-2705:
---------------------------------

You are asking to ignore the "Invalid join" exception when the query ask for a join with a component.

The ItemBase for NH does not have the property SubItem, in fact in the LINQ you are using the concrete subclass and not the base.

> 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: Improvement
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Andrei Alecu
>            Priority: Minor
>         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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2705) Linq/Hql/Criteria Fetch on class hierarchy generates invalid SQL when derivees mix component and many-to-one mappings

[Fabio M. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21088#action_21088 ] 

Fabio Maulo commented on NH-2705:
---------------------------------

Test available on trunk in
NHibernate.Test.NHSpecificTest.NH2705

> 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: Improvement
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Andrei Alecu
>            Priority: Minor
>         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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2615) Linq Fetch cannot traverse through components

[Fabio M. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21087#action_21087 ] 

Fabio Maulo commented on NH-2615:
---------------------------------

The test is available inside NH-2705 test.

> Linq Fetch cannot traverse through components
> ---------------------------------------------
>
>                 Key: NH-2615
>                 URL: http://216.121.112.228/browse/NH-2615
>             Project:  NHibernate
>          Issue Type: Improvement
>          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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2705) Linq/Hql/Criteria Fetch on class hierarchy generates invalid SQL when derivees mix component and many-to-one mappings

[Andrei A. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21086#action_21086 ] 

Andrei Alecu commented on NH-2705:
----------------------------------

Huh?

This is clearly a bug and not an improvement request. There is a SubItem property on ItemBase:

    public class ItemBase
    {
        public virtual int Id { get; set; }
        public virtual SubItemBase SubItem { get; set; }

    }

Wrong SQL is being generated, I don't see how asking for valid SQL is an improvement request.


> 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: Improvement
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Andrei Alecu
>            Priority: Minor
>         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

        

[nhibernate-issues] [NHJIRA] Commented: (NH-2705) Linq/Hql/Criteria Fetch on class hierarchy generates invalid SQL when derivees mix component and many-to-one mappings

[Fabio M. (JIRA) <nh...@gm...>]

    [ http://216.121.112.228/browse/NH-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21085#action_21085 ] 

Fabio Maulo commented on NH-2705:
---------------------------------

The query
from ItemWithComponentSubItem i left join fetch i.SubItem.Details
works as expected

The query
from ItemBase i left join fetch i.SubItem
is wrong due ItemBase does not have a property named "SubItem"

The query
from ItemWithComponentSubItem i left join fetch i.SubItem
shows the real "matter" of this issue: Invalid join exception.

The LINQ
session.Query<T>().Fetch(p => p.SubItem.Details).Where(p => p.SubItem.Name == name).ToList();
is NH-2615

> 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: Improvement
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Andrei Alecu
>            Priority: Minor
>         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

        

[nhibernate-issues] [NHJIRA] Created: (NH-2708) Cast<>() with a where clause fails with a NotSupportedException

[Sergey K. (JIRA) <nh...@gm...>]

Cast<>() with a where clause fails with a NotSupportedException
---------------------------------------------------------------

                 Key: NH-2708
                 URL: http://216.121.112.228/browse/NH-2708
             Project:  NHibernate
          Issue Type: Bug
          Components: Linq Provider
    Affects Versions: 3.1.0
            Reporter: Sergey Karpushev
            Priority: Major
         Attachments: cast.patch

Issue similar to NH-2375

Patch with a test and fix attached.

Test 'NHibernate.Test.Linq.WhereTests.CastWithWhere' failed: System.NotSupportedException : Specified method is not supported.
	Hql\Ast\ANTLR\PolymorphicQuerySourceDetector.cs(61,0): at NHibernate.Hql.Ast.ANTLR.PolymorphicQuerySourceDetector.GetClassName(IASTNode querySource)
	Hql\Ast\ANTLR\PolymorphicQuerySourceDetector.cs(27,0): at NHibernate.Hql.Ast.ANTLR.PolymorphicQuerySourceDetector.Process(IASTNode tree)
	Hql\Ast\ANTLR\AstPolymorphicProcessor.cs(30,0): at NHibernate.Hql.Ast.ANTLR.AstPolymorphicProcessor.Process()
	Hql\Ast\ANTLR\AstPolymorphicProcessor.cs(24,0): at NHibernate.Hql.Ast.ANTLR.AstPolymorphicProcessor.Process(IASTNode ast, ISessionFactoryImplementor factory)
	Hql\Ast\ANTLR\ASTQueryTranslatorFactory.cs(33,0): at NHibernate.Hql.Ast.ANTLR.ASTQueryTranslatorFactory.CreateQueryTranslators(IASTNode ast, String queryIdentifier, String collectionRole, Boolean shallow, IDictionary`2 filters, ISessionFactoryImplementor factory)
	Hql\Ast\ANTLR\ASTQueryTranslatorFactory.cs(27,0): at NHibernate.Hql.Ast.ANTLR.ASTQueryTranslatorFactory.CreateQueryTranslators(String queryIdentifier, IQueryExpression queryExpression, String collectionRole, Boolean shallow, IDictionary`2 filters, ISessionFactoryImplementor factory)
	Engine\Query\HQLExpressionQueryPlan.cs(34,0): at NHibernate.Engine.Query.HQLExpressionQueryPlan.CreateTranslators(String expressionStr, IQueryExpression queryExpression, String collectionRole, Boolean shallow, IDictionary`2 enabledFilters, ISessionFactoryImplementor factory)
	Engine\Query\HQLExpressionQueryPlan.cs(23,0): at NHibernate.Engine.Query.HQLExpressionQueryPlan..ctor(String expressionStr, IQueryExpression queryExpression, String collectionRole, Boolean shallow, IDictionary`2 enabledFilters, ISessionFactoryImplementor factory)
	Engine\Query\HQLExpressionQueryPlan.cs(17,0): at NHibernate.Engine.Query.HQLExpressionQueryPlan..ctor(String expressionStr, IQueryExpression queryExpression, Boolean shallow, IDictionary`2 enabledFilters, ISessionFactoryImplementor factory)
	Engine\Query\QueryPlanCache.cs(88,0): at NHibernate.Engine.Query.QueryPlanCache.GetHQLQueryPlan(IQueryExpression queryExpression, Boolean shallow, IDictionary`2 enabledFilters)
	Impl\AbstractSessionImpl.cs(312,0): at NHibernate.Impl.AbstractSessionImpl.GetHQLQueryPlan(IQueryExpression queryExpression, Boolean shallow)
	Impl\AbstractSessionImpl.cs(268,0): at NHibernate.Impl.AbstractSessionImpl.CreateQuery(IQueryExpression queryExpression)
	Linq\NhQueryProvider.cs(43,0): at NHibernate.Linq.NhQueryProvider.PrepareQuery(Expression expression, IQuery& query, NhLinqExpression& nhQuery)
	Linq\NhQueryProvider.cs(26,0): at NHibernate.Linq.NhQueryProvider.Execute(Expression expression)
	Linq\NhQueryProvider.cs(103,0): at NHibernate.Linq.NhQueryProvider.Execute[TResult](Expression expression)
	at System.Linq.Queryable.FirstOrDefault[TSource](IQueryable`1 source)
	Linq\WhereTests.cs(554,0): at NHibernate.Test.Linq.WhereTests.CastWithWhere()

-- 
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

        

[nhibernate-issues] [NHJIRA] Updated: (NH-2705) Linq/Hql/Criteria Fetch on class hierarchy generates invalid SQL when derivees mix component and many-to-one mappings

[Fabio M. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fabio Maulo updated NH-2705:
----------------------------

    Issue Type: Improvement  (was: Bug)

Changed to improv. since the Fetch (with join) on a component does not have sense.

> 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: Improvement
>          Components: Core
>    Affects Versions: 3.1.0
>            Reporter: Andrei Alecu
>            Priority: Minor
>         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

        

[nhibernate-issues] [NHJIRA] Updated: (NH-2615) Linq Fetch cannot traverse through components

[Fabio M. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fabio Maulo updated NH-2615:
----------------------------

    Issue Type: Improvement  (was: Bug)

Changed to improv. since the Fetch (with join) on a component does not have sense.

> Linq Fetch cannot traverse through components
> ---------------------------------------------
>
>                 Key: NH-2615
>                 URL: http://216.121.112.228/browse/NH-2615
>             Project:  NHibernate
>          Issue Type: Improvement
>          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

        

[nhibernate-issues] [NHJIRA] Updated: (NH-2705) Linq/Hql/Criteria Fetch on class hierarchy generates invalid SQL when derivees mix component and many-to-one mappings

[Fabio M. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fabio Maulo updated NH-2705:
----------------------------

    Priority: Minor  (was: Major)

> 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: Minor
>         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

        

[nhibernate-issues] [NHJIRA] Closed: (NH-802) Investigate possible use of MSBuild to build the project

[Fabio M. (JIRA) <nh...@gm...>]

     [ http://216.121.112.228/browse/NH-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fabio Maulo closed NH-802.
--------------------------

    Resolution: Won't Fix

After 5 years it is clear that there is no interest on fix this issue.

> Investigate possible use of MSBuild to build the project
> --------------------------------------------------------
>
>                 Key: NH-802
>                 URL: http://216.121.112.228/browse/NH-802
>             Project:  NHibernate
>          Issue Type: Task
>          Components: Toolset
>    Affects Versions: 1.2.0.Beta1, 2.1.0.Alpha1
>            Reporter: Sergej Koščejev
>            Priority: Minor
>
> Need to see whether MSBuild can handle everything that NAnt can, and maybe switch if so.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira