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-06-17 17:34:32
|
[ http://216.121.112.228/browse/NH-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21300#action_21300 ]
Fabio Maulo commented on NH-2125:
---------------------------------
I can't see any kind of difference.
Can you attach the case where you have experimented this issue ?
> Solution for NH2123 - Subselect in combination with a disjuction query causes an enormous memory cons
> -----------------------------------------------------------------------------------------------------
>
> Key: NH-2125
> URL: http://216.121.112.228/browse/NH-2125
> Project: NHibernate
> Issue Type: Patch
> Components: Core
> Affects Versions: 2.1.2.GA
> Reporter: martijn evens
> Priority: Minor
> Attachments: NH2123.patch
>
>
> Setup:
> Simple Parent object linked to a simple Child object. The Child object is lazy loaded via subselect.
> When running a criteria query with a large disjunction (2000 params) on the parent object, which returns about 4000 objects, around 550Meg of memory is consumed. Just running the query causes this memory consumption, the child objects are not even touched or lazy loaded. I made a comparison with version 2.0.1 where only 40 Meg is consumed.
> Fix:
> In Revision 3481, the method CreateSubselects in file Nhibernate\Loader\Loader.cs was changed. Instead of using pre-created subselect statements a new subselect statement is created every time resulting in the described behavior.
> Moving back to using pre-created subselect statements, but leaving the rest of the code intact solved the issue.
--
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: Kelly S. (JIRA) <nh...@gm...> - 2011-06-17 16:29:40
|
[ http://216.121.112.228/browse/NH-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21299#action_21299 ]
Kelly Stuard commented on NH-2317:
----------------------------------
I grabbed trunk and tried this out. This simple case has been fixed. However, further testing needs to be done to have it be a complete feature.
Sure this works:
artists.Take(10).Select(a => a.Id)
But these don't:
artists.OrderBy(a => a.Age).Take(10).Select(a => a.Id)
artists.Where(a => a.Age > 21).Take(10).Select(a => a.Id)
It fails with the original error. (PolymorphicQuerySourceDetector)
If this needs to have additional test cases or be another bug, please let me know; I'm still new around here. I'll be happy to do either/both.
> Select after Take does not work properly
> ----------------------------------------
>
> Key: NH-2317
> URL: http://216.121.112.228/browse/NH-2317
> Project: NHibernate
> Issue Type: Bug
> Components: Linq Provider
> Affects Versions: 3.0.0.Alpha2
> Reporter: Jose F. Romaniello
> Priority: Major
> Fix For: 3.2.0Beta2
>
> Attachments: NH2317.7z
>
>
> artists.Take(10).Select(a => a.Id) throws exception on
> NHibernate.Hql.Ast.ANTLR.PolymorphicQuerySourceDetector.GetClassName(IASTNode querySource) en PolymorphicQuerySourceDetector.cs: line 62
> artists.Select(a => a.Id).Take(10) works properly
> These two queries work with the old provider.
--
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-06-17 12:06:25
|
[ http://216.121.112.228/browse/NH-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fabio Maulo resolved NH-2770.
-----------------------------
Resolution: Fixed
Fix Version/s: 3.2.0Beta2
> Property spelling of IDbIntegrationConfigurationProperties.LogFormatedSql
> -------------------------------------------------------------------------
>
> Key: NH-2770
> URL: http://216.121.112.228/browse/NH-2770
> Project: NHibernate
> Issue Type: Improvement
> Components: Mapping by-code
> Affects Versions: 3.2.0Beta1
> Reporter: Michael Teper
> Fix For: 3.2.0Beta2
>
>
> The property should be named LogFormattedSql (note the double "t")
--
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: Kenneth O. (JIRA) <nh...@gm...> - 2011-06-17 10:56:26
|
Lazy-collection not loaded when a property is Lazy-loaded
---------------------------------------------------------
Key: NH-2772
URL: http://216.121.112.228/browse/NH-2772
Project: NHibernate
Issue Type: Bug
Components: Core
Affects Versions: 3.2.0Beta1
Reporter: Kenneth Olsen
Priority: Major
Attachments: NHibernateJira.zip
The NHibernate version is latest trunk as of today (17th of June 2011)
Lazy-collection is not loaded, when a property in parent class is marked as Lazy.
See attahced test solution
--
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: G. H. (JIRA) <nh...@gm...> - 2011-06-17 08:03:23
|
return-join does not suport discriminator usage
-----------------------------------------------
Key: NH-2771
URL: http://216.121.112.228/browse/NH-2771
Project: NHibernate
Issue Type: New Feature
Components: Core
Affects Versions: 3.0.0.GA
Reporter: G. Horstman
Priority: Minor
When using named-queries in a hbm-file, you can not assign a discriminator column to the <return-join> part of the query.
I expected that I could use the <return-discriminator> as I can use it on the <return class="some.name, some.assembly"> part of the query.
Hopefully this is enough information on this subject.
--
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: Michael T. (JIRA) <nh...@gm...> - 2011-06-16 19:04:22
|
Property spelling of IDbIntegrationConfigurationProperties.LogFormatedSql
-------------------------------------------------------------------------
Key: NH-2770
URL: http://216.121.112.228/browse/NH-2770
Project: NHibernate
Issue Type: Improvement
Components: Mapping by-code
Affects Versions: 3.2.0Beta1
Reporter: Michael Teper
The property should be named LogFormattedSql (note the double "t")
--
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: cremor (JIRA) <nh...@gm...> - 2011-06-16 08:54:28
|
[ http://216.121.112.228/browse/NH-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
cremor updated NH-2769:
-----------------------
Attachment: NH2769 patch.patch
> Linq Fetch over component has no effect on generated SQL
> --------------------------------------------------------
>
> Key: NH-2769
> URL: http://216.121.112.228/browse/NH-2769
> Project: NHibernate
> Issue Type: Bug
> Components: Linq Provider
> Affects Versions: 3.2.0Beta1
> Reporter: cremor
> Priority: Major
> Attachments: NH2769 patch.patch
>
>
> NH-2615 fixed the exceptions that occured when a Linq query with a fetch on a component was executed but the fetch has still no effect on the generated SQL.
> Attached is a patch that modifies the already existing test (NHSpecificTest\NH2705) so it also checks the generated statement.
--
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: cremor (JIRA) <nh...@gm...> - 2011-06-16 08:54:19
|
Linq Fetch over component has no effect on generated SQL
--------------------------------------------------------
Key: NH-2769
URL: http://216.121.112.228/browse/NH-2769
Project: NHibernate
Issue Type: Bug
Components: Linq Provider
Affects Versions: 3.2.0Beta1
Reporter: cremor
Priority: Major
Attachments: NH2769 patch.patch
NH-2615 fixed the exceptions that occured when a Linq query with a fetch on a component was executed but the fetch has still no effect on the generated SQL.
Attached is a patch that modifies the already existing test (NHSpecificTest\NH2705) so it also checks the generated statement.
--
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: Onur G. (JIRA) <nh...@gm...> - 2011-06-16 07:56:32
|
[ http://216.121.112.228/browse/NH-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21298#action_21298 ]
Onur Gumus commented on NH-517:
-------------------------------
Please give this issue more priority. It is important for me. It causes very low performance if you load a bunch of child classes first.
> Unnecessary selects when mapped as class instead of column
> ----------------------------------------------------------
>
> Key: NH-517
> URL: http://216.121.112.228/browse/NH-517
> Project: NHibernate
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.0.1
> Reporter: Ruurd Boeke
> Priority: Major
> Attachments: NH517.rar
>
>
> I've delved deeper into the problem described by: http://jira.nhibernate.org/browse/NH-435
> It seems I have the same kind of problem, but it has nothing to do with using an outer select.
> Short summary: I'm getting N selects when I have mapped a one-to-many relation, and in the many-side, the composite-ID maps towards the 'one' with a key-many-to-one instead of a key-property.
> This means that nHibernate is using one well-constructed query to get all the info it needs, and then sends a SELECT for every row it got back like this: select parentID from parents where parentID = :parentid
> In my current situation, this leads to several thousands of selects.
--
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: Daniel G. (JIRA) <nh...@gm...> - 2011-06-15 18:24:34
|
[ http://216.121.112.228/browse/NH-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21297#action_21297 ]
Daniel Guenter commented on NH-1681:
------------------------------------
Yes it is the same.
> Update Join element to support keys with property-refs
> ------------------------------------------------------
>
> Key: NH-1681
> URL: http://216.121.112.228/browse/NH-1681
> Project: NHibernate
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.1.0.Alpha1
> Reporter: Daniel Guenter
> Priority: Minor
> Attachments: NH3.0.0.GA ref join.patch, NHibernateJoinPatch.patch
>
>
> <join> element has typically only supported joining to PK of owning table. Sometimes this is limiting especially in dealing with legacy databases where multiple unique keys may be present. It would be nice to be able to specify a property-ref in the <key> element.
> Patch included updates functionality to add the aforementioned improvement. The only caveat is that the column mapped as the property-ref must be marked as unique as well. This patch is kind of invasive as it has to change major functionality to allow specifying of alternate ID's on save/update/delete and in the join query. This patch also supports proper exporting of the schema.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: David M. (JIRA) <nh...@gm...> - 2011-06-15 18:22:47
|
[ http://216.121.112.228/browse/NH-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21296#action_21296 ]
David McClelland commented on NH-1452:
--------------------------------------
Is this the same as NH-1681? We'd love to see this patch rolled into the trunk.
> Join element doesn't support keys with property-refs
> ----------------------------------------------------
>
> Key: NH-1452
> URL: http://216.121.112.228/browse/NH-1452
> Project: NHibernate
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.0.CR2
> Reporter: Brian Rumschlag
> Priority: Major
> Attachments: 1452.patch, NH1452.patch
>
>
> The <join> element does not use the property-ref attribute on it's <key>.
> It will always join to the child table by the primary key.
> Attached is the failing test case.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://216.121.112.228/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: David M. (JIRA) <nh...@gm...> - 2011-06-15 18:20:33
|
[ http://216.121.112.228/browse/NH-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21295#action_21295 ]
David McClelland commented on NH-1681:
--------------------------------------
Is this the same as NH-1452?
> Update Join element to support keys with property-refs
> ------------------------------------------------------
>
> Key: NH-1681
> URL: http://216.121.112.228/browse/NH-1681
> Project: NHibernate
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.1.0.Alpha1
> Reporter: Daniel Guenter
> Priority: Minor
> Attachments: NH3.0.0.GA ref join.patch, NHibernateJoinPatch.patch
>
>
> <join> element has typically only supported joining to PK of owning table. Sometimes this is limiting especially in dealing with legacy databases where multiple unique keys may be present. It would be nice to be able to specify a property-ref in the <key> element.
> Patch included updates functionality to add the aforementioned improvement. The only caveat is that the column mapped as the property-ref must be marked as unique as well. This patch is kind of invasive as it has to change major functionality to allow specifying of alternate ID's on save/update/delete and in the join query. This patch also supports proper exporting of the schema.
--
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: Himanshu K. (JIRA) <nh...@gm...> - 2011-06-15 08:28:18
|
Programmaticaly switching lazy initialization off on certain properties
------------------------------------------------------------------------------
Key: NH-2768
URL: http://216.121.112.228/browse/NH-2768
Project: NHibernate
Issue Type: Improvement
Components: Core
Affects Versions: 3.1.0
Reporter: Himanshu Kodwani
Nhibernate supports lazy initialization. In some scenarios I prefer few properties to initialize lazily but other times I want those properties to be fetched along with the entity itself in a single select and join statement. This will give better performance when the user knows in advance what properties he'll be working on.
Something like:
eg. ISession session.SwitchoffLazyOn("Invoice.InvoiceLines");
now when we'll fetch an invoice, invoice lines will be fetched along with it in a single sql join statement without the need for sending another sql statement to the db.
If you already have such a feature then kindly let me know what section of the documentation covers it.
--
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: Julian M. (JIRA) <nh...@gm...> - 2011-06-14 15:37:14
|
[ http://216.121.112.228/browse/NH-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Maughan resolved NH-2760.
--------------------------------
Resolution: Fixed
Committed to trunk (r5926)
> Unable to order by sub-collection's count
> -----------------------------------------
>
> Key: NH-2760
> URL: http://216.121.112.228/browse/NH-2760
> Project: NHibernate
> Issue Type: Improvement
> Components: Linq Provider
> Affects Versions: 3.2.0Beta1
> Reporter: Kelly Stuard
> Priority: Major
> Fix For: 3.2.0Beta2
>
> Attachments: NH2760-Exception.txt, NH2760.zip
>
>
> // Many-to-many association between User and UserGroup.
> var query =
> from ug in session.Query<UserGroup>()
> orderby ug.Users.Count()
> select ug;
> query.ToList();
> // Exception of type 'Antlr.Runtime.NoViableAltException' was thrown.
--
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: Julian M. (JIRA) <nh...@gm...> - 2011-06-14 15:35:15
|
[ http://216.121.112.228/browse/NH-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Maughan updated NH-2760:
-------------------------------
Fix Version/s: 3.2.0Beta2
Description:
// Many-to-many association between User and UserGroup.
var query =
from ug in session.Query<UserGroup>()
orderby ug.Users.Count()
select ug;
query.ToList();
// Exception of type 'Antlr.Runtime.NoViableAltException' was thrown.
was:
(Attaching unit tests and exception shortly.)
// Many-to-many association between User and UserGroup.
var query =
from ug in session.Query<UserGroup>()
orderby ug.Users.Count()
select ug;
query.ToList();
// Exception of type 'Antlr.Runtime.NoViableAltException' was thrown.
Issue Type: Improvement (was: Bug)
Thanks for the test. I've committed a change that makes it pass.
The Linq statement now generates the same SQL as the equivalent HQL statement: "select ug from UserGroup ug order by size(ug.Users)"...
select
usergroup0_.Id as Id2_,
usergroup0_.Name as Name2_,
usergroup0_.Other as Other2_
from
UserGroup usergroup0_
order by
(select cast(count(*) as INT)
from UserGroupUsers users1_, [User] user2_
where usergroup0_.Id=users1_.UserGroupId
and users1_.UserId=user2_.Id) asc
Unfortunately some RDBMs may have trouble with the subquery in the ORDER BY clause.
> Unable to order by sub-collection's count
> -----------------------------------------
>
> Key: NH-2760
> URL: http://216.121.112.228/browse/NH-2760
> Project: NHibernate
> Issue Type: Improvement
> Components: Linq Provider
> Affects Versions: 3.2.0Beta1
> Reporter: Kelly Stuard
> Priority: Major
> Fix For: 3.2.0Beta2
>
> Attachments: NH2760-Exception.txt, NH2760.zip
>
>
> // Many-to-many association between User and UserGroup.
> var query =
> from ug in session.Query<UserGroup>()
> orderby ug.Users.Count()
> select ug;
> query.ToList();
> // Exception of type 'Antlr.Runtime.NoViableAltException' was thrown.
--
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-06-14 14:58:23
|
[ http://216.121.112.228/browse/NH-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21292#action_21292 ]
Fabio Maulo commented on NH-2767:
---------------------------------
In the session-factory there is already just one instance but mappings are parsed before create the session-factory.
> Make the Register* Methods on Dialect Public
> --------------------------------------------
>
> Key: NH-2767
> URL: http://216.121.112.228/browse/NH-2767
> Project: NHibernate
> Issue Type: Improvement
> Components: DataProviders / Dialects
> Affects Versions: 3.2.0Beta2
> Reporter: Ricardo Peres
>
> In order to make extensibility more easy, the Register* methods on Dialect could be made public. This way, every time we want to register, for example, a custom SQL function, we don't have to subclass all dialects that we need, and we only need to call the new RegisterFunction method on the current dialect.
> Since this is a breaking change, because now these functions are protected, perhaps additional public overloads could be added.
--
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: Ricardo P. (JIRA) <nh...@gm...> - 2011-06-14 14:45:20
|
[ http://216.121.112.228/browse/NH-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21291#action_21291 ]
Ricardo Peres commented on NH-2767:
-----------------------------------
But don't you see any value in allowing runtime registration of SQL functions?
I know I asked you before, and you said "so and so", if I recall correctly...
> Make the Register* Methods on Dialect Public
> --------------------------------------------
>
> Key: NH-2767
> URL: http://216.121.112.228/browse/NH-2767
> Project: NHibernate
> Issue Type: Improvement
> Components: DataProviders / Dialects
> Affects Versions: 3.2.0Beta2
> Reporter: Ricardo Peres
>
> In order to make extensibility more easy, the Register* methods on Dialect could be made public. This way, every time we want to register, for example, a custom SQL function, we don't have to subclass all dialects that we need, and we only need to call the new RegisterFunction method on the current dialect.
> Since this is a breaking change, because now these functions are protected, perhaps additional public overloads could be added.
--
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: Ricardo P. (JIRA) <nh...@gm...> - 2011-06-14 14:43:20
|
[ http://216.121.112.228/browse/NH-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21290#action_21290 ]
Ricardo Peres commented on NH-2767:
-----------------------------------
That's exactly what I said: register functions on the session factory. Take a look at the second code sample I sent.
If you say different instances of the Dialect may be used, doesn't that sound to unnecessary instance creation? Shouldn't there be one and only one Dialect instance for a session factory?
> Make the Register* Methods on Dialect Public
> --------------------------------------------
>
> Key: NH-2767
> URL: http://216.121.112.228/browse/NH-2767
> Project: NHibernate
> Issue Type: Improvement
> Components: DataProviders / Dialects
> Affects Versions: 3.2.0Beta2
> Reporter: Ricardo Peres
>
> In order to make extensibility more easy, the Register* methods on Dialect could be made public. This way, every time we want to register, for example, a custom SQL function, we don't have to subclass all dialects that we need, and we only need to call the new RegisterFunction method on the current dialect.
> Since this is a breaking change, because now these functions are protected, perhaps additional public overloads could be added.
--
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-06-14 14:39:24
|
[ http://216.121.112.228/browse/NH-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21289#action_21289 ]
Fabio Maulo commented on NH-2760:
---------------------------------
Which should be the expected SQL ?
> Unable to order by sub-collection's count
> -----------------------------------------
>
> Key: NH-2760
> URL: http://216.121.112.228/browse/NH-2760
> Project: NHibernate
> Issue Type: Bug
> Components: Linq Provider
> Affects Versions: 3.2.0Beta1
> Reporter: Kelly Stuard
> Priority: Major
> Attachments: NH2760-Exception.txt, NH2760.zip
>
>
> (Attaching unit tests and exception shortly.)
> // Many-to-many association between User and UserGroup.
> var query =
> from ug in session.Query<UserGroup>()
> orderby ug.Users.Count()
> select ug;
> query.ToList();
> // Exception of type 'Antlr.Runtime.NoViableAltException' was thrown.
--
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-06-14 14:35:25
|
[ http://216.121.112.228/browse/NH-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fabio Maulo closed NH-2767.
---------------------------
Resolution: Won't Fix
> Make the Register* Methods on Dialect Public
> --------------------------------------------
>
> Key: NH-2767
> URL: http://216.121.112.228/browse/NH-2767
> Project: NHibernate
> Issue Type: Improvement
> Components: DataProviders / Dialects
> Affects Versions: 3.2.0Beta2
> Reporter: Ricardo Peres
>
> In order to make extensibility more easy, the Register* methods on Dialect could be made public. This way, every time we want to register, for example, a custom SQL function, we don't have to subclass all dialects that we need, and we only need to call the new RegisterFunction method on the current dialect.
> Since this is a breaking change, because now these functions are protected, perhaps additional public overloads could be added.
--
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-06-14 14:35:24
|
[ http://216.121.112.228/browse/NH-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21288#action_21288 ]
Fabio Maulo commented on NH-2767:
---------------------------------
The dialect instance resides in the SessionFactory.
var dialectUsedByAllSessions = ((ISessionFactoryImplementor)sessionFactory).Dialect;
The only point where the registration of a HQL-function have some sense is, at most, after build the session-factory. There is no sense to do it again and again each time a session is opened (FYI internally HQL functions instances are saved in a Dictionary where the Key is the function's name).
On the other side, different instances of the dialect may be used during the parsing of named-queries that mean that there is no way to be 100% that everything will work if you don't register your HQL functions using the Dialect ctor.
> Make the Register* Methods on Dialect Public
> --------------------------------------------
>
> Key: NH-2767
> URL: http://216.121.112.228/browse/NH-2767
> Project: NHibernate
> Issue Type: Improvement
> Components: DataProviders / Dialects
> Affects Versions: 3.2.0Beta2
> Reporter: Ricardo Peres
>
> In order to make extensibility more easy, the Register* methods on Dialect could be made public. This way, every time we want to register, for example, a custom SQL function, we don't have to subclass all dialects that we need, and we only need to call the new RegisterFunction method on the current dialect.
> Since this is a breaking change, because now these functions are protected, perhaps additional public overloads could be added.
--
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: Ricardo P. (JIRA) <nh...@gm...> - 2011-06-14 14:10:25
|
[ http://216.121.112.228/browse/NH-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21287#action_21287 ]
Ricardo Peres commented on NH-2767:
-----------------------------------
Sorry, what I mean is: with the sample C# code I provided, we register a function through a ISession (I know the registration is made on the Dialect, but I didn't knew how to get to the Dialect). Now I now we can use something like this, on a session factory instead of a session:
public static class DialectExtensions
{
private static readonly MethodInfo registerFunctionMethod = typeof(Dialect).GetMethod("RegisterFunction", BindingFlags.Instance | BindingFlags.NonPublic);
public static void RegisterFunction(this Dialect dialect, String name, ISQLFunction function)
{
registerFunctionMethod.Invoke(dialect, new Object[] { name, function });
}
public static void RegisterFunction<T>(this ISessionFactory factory, String name, String sql)
{
IType type = NHibernateUtil.GuessType(typeof(T));
SQLFunctionTemplate template = new SQLFunctionTemplate(type, sql);
RegisterFunction(factory, name, template);
}
public static void RegisterFunction(this ISessionFactory factory, String name, ISQLFunction function)
{
registerFunctionMethod.Invoke(GetDialect(factory), new Object[] { name, function });
}
public static Dialect GetDialect(this ISessionFactory factory)
{
return((factory as SessionFactoryImpl).Dialect);
}
}
This is a simple, very low priority request. Feel free to ignore it, if you think it is not necessary.
> Make the Register* Methods on Dialect Public
> --------------------------------------------
>
> Key: NH-2767
> URL: http://216.121.112.228/browse/NH-2767
> Project: NHibernate
> Issue Type: Improvement
> Components: DataProviders / Dialects
> Affects Versions: 3.2.0Beta2
> Reporter: Ricardo Peres
>
> In order to make extensibility more easy, the Register* methods on Dialect could be made public. This way, every time we want to register, for example, a custom SQL function, we don't have to subclass all dialects that we need, and we only need to call the new RegisterFunction method on the current dialect.
> Since this is a breaking change, because now these functions are protected, perhaps additional public overloads could be added.
--
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-06-14 13:59:23
|
[ http://216.121.112.228/browse/NH-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21286#action_21286 ]
Fabio Maulo commented on NH-2767:
---------------------------------
I can't catch the improvement.
What mean "This way, we don't have to register the function each time a new session is created." ?
> Make the Register* Methods on Dialect Public
> --------------------------------------------
>
> Key: NH-2767
> URL: http://216.121.112.228/browse/NH-2767
> Project: NHibernate
> Issue Type: Improvement
> Components: DataProviders / Dialects
> Affects Versions: 3.2.0Beta2
> Reporter: Ricardo Peres
>
> In order to make extensibility more easy, the Register* methods on Dialect could be made public. This way, every time we want to register, for example, a custom SQL function, we don't have to subclass all dialects that we need, and we only need to call the new RegisterFunction method on the current dialect.
> Since this is a breaking change, because now these functions are protected, perhaps additional public overloads could be added.
--
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: Ricardo P. (JIRA) <nh...@gm...> - 2011-06-14 11:43:20
|
[ http://216.121.112.228/browse/NH-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21285#action_21285 ]
Ricardo Peres commented on NH-2767:
-----------------------------------
I mean, access the current dialect from the session factory, since it is easy to access it from the session.
public static Dialect GetDialect(this ISession session)
{
return(session.GetSessionImplementation().Factory.Dialect);
}
This way, we don't have to register the function each time a new session is created.
> Make the Register* Methods on Dialect Public
> --------------------------------------------
>
> Key: NH-2767
> URL: http://216.121.112.228/browse/NH-2767
> Project: NHibernate
> Issue Type: Improvement
> Components: DataProviders / Dialects
> Affects Versions: 3.2.0Beta2
> Reporter: Ricardo Peres
>
> In order to make extensibility more easy, the Register* methods on Dialect could be made public. This way, every time we want to register, for example, a custom SQL function, we don't have to subclass all dialects that we need, and we only need to call the new RegisterFunction method on the current dialect.
> Since this is a breaking change, because now these functions are protected, perhaps additional public overloads could be added.
--
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: Ricardo P. (JIRA) <nh...@gm...> - 2011-06-14 11:38:18
|
[ http://216.121.112.228/browse/NH-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21284#action_21284 ]
Ricardo Peres commented on NH-2767:
-----------------------------------
Of course, in order for this to work, we would need an easy way to get access to the current dialect.
> Make the Register* Methods on Dialect Public
> --------------------------------------------
>
> Key: NH-2767
> URL: http://216.121.112.228/browse/NH-2767
> Project: NHibernate
> Issue Type: Improvement
> Components: DataProviders / Dialects
> Affects Versions: 3.2.0Beta2
> Reporter: Ricardo Peres
>
> In order to make extensibility more easy, the Register* methods on Dialect could be made public. This way, every time we want to register, for example, a custom SQL function, we don't have to subclass all dialects that we need, and we only need to call the new RegisterFunction method on the current dialect.
> Since this is a breaking change, because now these functions are protected, perhaps additional public overloads could be added.
--
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.
