Thanks Fabio for the information. This was not so much about
automatically quoting the table/column names (as discussed in the link
you sent) but rather about applying the parent entity alias when using
a Formula that contains a data-type in it (e.g. a CAST or CONVERT). It
was not recognizing the data type name ('INT' for example) as a
keyword, and it decided to apply the outer entity alias to it. (see
example in my original post)

I have created a patch for this issue which seems much more
"important" than automatically quoting column or table names, as this
is actually broken with no real work-around if you have to use a CAST
statement in the formula

The patch is very simple (two lines) and I believe is the correct way
to fix this issue. Take a look at the patch I submitted for the
details:
http://jira.nhibernate.org/browse/NH-1617

regards,
Thunder


On Dec 17, 8:55 am, "Fabio Maulo" <[email protected]> wrote:
> hahahahaha :)  at the end somebody are asking for 
> ithttp://jira.nhibernate.org/browse/NH-188
>
> That was an old issue in NH (under JBOSS) that was closed as "Won't fix"
> but, then, they start the same work in H3.
> As you can see in that issue I'm very interested to fix the problem of
> RDBMS-keyword in some way...
> We will check if it will possible for NH2.1.0 (next version).
> BTW I think that, in your case, you can simply add a function to the
> dialect.
>
> 2008/12/17 Thunder <[email protected]>
>
>
>
>
>
> > OK, I have located the problem, and I have a two-line fix I will look
> > at submitting (never filed a bug OR submitted a fix, so I don't know
> > the process). Here's the details:
>
> > in NHibernate.SqlCommand.Template::RenderWhereStringTemplate, line 173
> > (in 2.0.1 GA) is looking to see if it should add the placeholder for
> > the table alias:
>
> >                                else if (
> >                                        IsIdentifier(token, dialect) &&
> >                                        !IsFunctionOrKeyword(lcToken,
> > nextToken, dialect,
> > functionRegistry)
> >                                        )
> >                                {
> >                                        result.Append(placeholder)
> >                                                .Append('.')
> >                                                .Append(token);
> >                                }
>
> > The call to "IsFunctionOrKeyword" was not picking up any data type
> > names as keywords. Upon inspecting this function I found:
>
> >                        return "(".Equals(nextToken) ||
> >                               Keywords.Contains(lcToken) ||
> >                               functionRegistry.HasFunction(lcToken) ||
> >                               // TODO H3:
> > dialect.Keywords.Contains(lcToken) ||
> >                               FunctionKeywords.Contains(lcToken);
>
> > The commented TODO line indicates that someone was thinking about
> > asking the dialect what keywords it knew about in addition to the
> > Template keywords. I started by un-commenting this line (change 1 of
> > two)
>
> > I then realized that the SQL 2000 dialect did not have ANYTHING listed
> > in it's Keywords collection. It did have calls to "RegisterColumnType"
> > with all the different supported data types. Well, all datatypes
> > should be treated as keywords too, so I simply added a call to
> > "RegisterKeyword" from in the function "RegisterColumnType" as shown
> > below:
>
> >                protected void RegisterColumnType(DbType code, string name)
> >                {
> >                        // 12/16/08 - data types are also keywords.
> >                        RegisterKeyword(name.ToLower());
>
> >                        typeNames.Put(code, name);
> >                }
>
> > I have not tested this with other dialects, nor done any thorough
> > testing, but these two changes seem correct.  If anyone has any
> > comments or suggestions on how I need to go about submitting a bug and
> > fix, please let me know!
>
> > Thanks!
> > Thunder
>
> > On Dec 16, 3:25 pm, Thunder <[email protected]> wrote:
> > > Hello,
>
> > > I have searched around on the board, and elsewhere on the internet and
> > > cannot seem to find any answers to this problem. Also I have started
> > > debugging into the nHibernate 2.0.1 source, but can't seem to see
> > > where the aliasing is applied in the formula.
>
> > > I have an entity called 'Event' with a property formula that looks
> > > like this:
> > > <property name="CoachingStatus">
> > > <formula>
> > > (SELECT MIN(CONVERT(int,ec.CounselStatus))) FROM dbo.l_EventCounsel ec
> > > WHERE ec.eventid=eventid)
> > > </formula>
> > > </property>
>
> > > The problem I am having is that the data type (int in this case, but I
> > > have tried integer, bigint, and tinyint) is being considered as a
> > > column and getting the outer table's alias?!
>
> > > (SELECT MIN(CONVERT(this_.int,ec.CounselStatus))) FROM
> > > dbo.l_EventCounsel ec WHERE ec.eventid=this_.eventid)
>
> > > SQL Server then chokes on the query. Are there any rules as to when an
> > > alias is applied? The only NH documentation I can find says:
> > > "Note that you can reference the entities own table by not declaring
> > > an alias on a particular column"
> > > and this post (http://ayende.com/Blog/archive/2006/10/01/
> > > UsingSQLFunctionsInNHibernate.aspx) from Ayende says:
> > > "NHibernate will automatically pre-pend the alias of the current
> > > entity table to anything that looks like a unqualified column access."
>
> > > I'm glad to dig into why and even work on a solution, but I kinda need
> > > a head-start as to where to look in the code for this functionality.
>
> > > thanks in advance,
> > > Thunder
>
> > > P.S. My Environment:
> > > NHibernate 2.0.1
> > > SQL Server 2005
> > > VisualStudio 2008 SP1
>
> --
> Fabio Maulo
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to