[jira] Commented: (IBATISNET-29) Pound signs not handled correctly when used in combination with $Foo$ syntax and dynamic sql.

["Ron Grabowski (JIRA)" <ib...@incubator.apache.org>]

     [ http://issues.apache.org/jira/browse/IBATISNET-29?page=comments#action_62228 ]
     
Ron Grabowski commented on IBATISNET-29:
----------------------------------------

If my sql is incorrect, then the incorrect sql should be sent to the database. If I sent invalid sql to the database:

 SELECT 5, *, -2 FROM 1+1 WHERE a=b

Ibatis should just pass that through and not throw any exceptions. The sql isn't being sent to the database becuase Ibatis is throwing a ProbeException when populating the dynamic sql.

Suppose I am building a system to manage music bands. One of my clients is named:

 #The Pound Signs#

I insert their name into the database manually using the following sql statement:

 INSERT INTO Band (Name) VALUES ('#The Pound Signs#')

I want to use the following syntax to retrieve them from the database based on their name:

 <select parameterClass="map" resultClass="string">
  SELECT Name FROM Band WHERE Name = '##$BandName$##'
 </select>

According to PreparedStatementFactory, Ibatis parses that as:

 SELECT Name FROM Band WHERE Name = '?'

When it should be parsed as:

 SELECT Name FROM Band WHERE Name = '#?#'

If I create a Hashtable called map and set a key named BandName:

 map["BandName"] = "The Pound Signs";

I will never get a match becuase the ## have been removed rather than being replaced by a literal #. 

The Java version of IBatis uses the double pound sign to denote a literal pound sign:

 http://tinyurl.com/44je6
 http://www.mail-archive.com/ibatis-user-java@incubator.apache.org/msg01358.html

Does the .Net version use the same notation? How do use the dollar sign notation (i.e. $xyz$) to send a string that has a pound sign on either side of it?

Here is another example. Suppose the band signs a big record contract and changes their name to:

 12#34The Pound Signs56#78

Ibatis parses the following statement:

 <select parameterClass="map" resultClass="string">
  SELECT Name FROM Band WHERE Name = '12##34$BandName$56##78'
 </select>

As:

 SELECT Name FROM Band WHERE Name = '12?78'

That's not right, 34 and 56 have been removed. It should be:

 SELECT Name FROM Band WHERE Name = '12#34?56#78'

While neither of those examples throw ProbeExceptions, I have a feeling they are related to my original bug report.

> Pound signs not handled correctly when used in combination with $Foo$ syntax and dynamic sql.
> ---------------------------------------------------------------------------------------------
>
>          Key: IBATISNET-29
>          URL: http://issues.apache.org/jira/browse/IBATISNET-29
>      Project: iBatis for .NET
>         Type: Bug
>     Versions: DataMapper 1.1
>  Environment: IBatisNet.DataMapper
> [assembly: AssemblyVersion("1.1.458")]
>     Reporter: Ron Grabowski
>     Assignee: Gilles Bayon

>
> When the following syntax is used:
>  ##$Foo$##
> and Foo is set via:
>  map["Foo"] = new DateTime(2005, 1, 2, 3, 4, 5);
> Ibatis seems to process the line correctly. I expect the following text to be sent to the database:
>  #1/2/2005 3:04:05#
> The logs don't explicitly state that that text is being sent to the database but the code seems to work correctly.
> When a dynamic sql block is used with the ##$Foo$## syntax, Ibatis incorrectly throws a ProbeException because it tries to re-evaluate "1/2/2005 3:04:05" as a key in the Hashtable. For example this snippet of text:
> (Concert.ConcertDate = ##$StartDate$##)
> <isNotEmpty prepend="AND" property="EndDate">
>  (Concert.ConcertDate = ##$EndDate$##)
> </isNotEmpty>
> Raises a ProbeException with the following error message: There is no Get property named '1/2/2005 3' in class 'Hashtable'. The next character after the 3 is a colon which Ibatis uses for inline parameters. It appears that Ibatis is trying to re-evaluate what's between the dollar signs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira