K, There were enough people interested, and it only took 10 seconds to add
support for line breaks and tabs etc. into the inline parameters... so I
added it.
Clinton
On Fri, Feb 5, 2010 at 8:45 AM, Marco Speranza
<marco.speranz...@gmail.com>wrote:
> Hi Clinton,
>
> I totally agree with you when you speak about format but let me
> explain better: there are customers QA that impose strict coding rules
> - XML files included - and one of them checks if a codeline is
> contained in 'n' chars.
> Even if nobody agree, in this scenario the QA
> could not accept iBatis SQL map files, and that could be a very big
> mess in my project.
>
> I'm sure I'm not the only developer in this situation, so having
> iBatis excluded by QAs because of file format could be a very big
> shame :(
>
> Finally I didn't understand if there are some technical motivation of
> your decision, if iBatis supports the line break on the parameter
> structure, users can choose they preferred formatting style.
>
> Thanks a lot
>
>
>
> 2010/2/4 Clinton Begin <clinton.be...@gmail.com>
>
>> PS: And yes, I will correct the documentation. That was done because I
>> don't think it fit on one line.
>>
>> It should be extremely rare to use the attributes at all, and when you do,
>> it will be one or two at most...
>>
>> For example, the following are likely mappings, in order of likelyhood:
>>
>> *#{some_column}
>> *-- 90% of the time, this should be all you need.
>>
>> *#{some_column, jdbcType=NUMERIC}
>> *-- This is for nullable columns, and even then, only where you expect to
>> pass null.
>>
>> *#{some_column, javaType=String, jdbcType=CLOB}
>> *-- perhaps to force a clob mapping with a simple JDBC driver that
>> doesn't do this behind getString().
>>
>> *#{some_column, typeHandler=MyTypeHandler}
>> *-- custom type handler (no need to specify types at this point, all
>> they're used for is to look up the type handler).
>>
>> *#{some_column, jdbcType=NUMERIC, typeHandler=MyTypeHandler}
>> *-- This is the worst possible case I can think of... a nullable column
>> with a custom type handler that is mapped on a per-statement basis (a
>> globally defined typehandler wouldn't even need this).
>>
>> Furthermore, I can't see why you would ever format your SQL statements in
>> such a way that would require a line break in the middle.
>>
>> For any WHERE clause or SET clause you'll have (in the worst possible
>> case):
>>
>> SET
>> foo = *#{some_column, jdbcType=NUMERIC, typeHandler=MyTypeHandler} *
>> WHERE
>> bar = *#{some_column, jdbcType=NUMERIC, typeHandler=MyTypeHandler} *
>>
>> Is this more readable?
>>
>> SET
>> foo = *#{some_column,
>> jdbcType=NUMERIC,
>> typeHandler=MyTypeHandler} *
>> WHERE
>> bar = *#{some_column,
>> jdbcType=NUMERIC,
>> typeHandler=MyTypeHandler} *
>>
>> What about at scale?
>>
>> SET
>> foo = *#{some_column, jdbcType=NUMERIC, typeHandler=MyTypeHandler} *
>> foo = *#{some_column, jdbcType=NUMERIC, typeHandler=MyTypeHandler} *
>> foo = *#{some_column, jdbcType=NUMERIC, typeHandler=MyTypeHandler} *
>> foo = *#{some_column, jdbcType=NUMERIC, typeHandler=MyTypeHandler} *
>> foo = *#{some_column, jdbcType=NUMERIC, typeHandler=MyTypeHandler} *
>> WHERE
>> bar = *#{some_column, jdbcType=NUMERIC, typeHandler=MyTypeHandler} *
>> bar = *#{some_column, jdbcType=NUMERIC, typeHandler=MyTypeHandler} *
>> bar = *#{some_column, jdbcType=NUMERIC, typeHandler=MyTypeHandler} *
>> bar = *#{some_column, jdbcType=NUMERIC, typeHandler=MyTypeHandler} *
>> bar = *#{some_column, jdbcType=NUMERIC, typeHandler=MyTypeHandler} *
>> bar = *#{some_column, jdbcType=NUMERIC, typeHandler=MyTypeHandler} *
>>
>> SET
>> foo = *#{some_column,
>> jdbcType=NUMERIC,
>> typeHandler=MyTypeHandler} *
>> foo = *#{some_column,
>> jdbcType=NUMERIC,
>> typeHandler=MyTypeHandler} *
>> foo = *#{some_column,
>> jdbcType=NUMERIC,
>> typeHandler=MyTypeHandler} *
>> foo = *#{some_column,
>> jdbcType=NUMERIC,
>> typeHandler=MyTypeHandler} *
>> foo = *#{some_column,
>> jdbcType=NUMERIC,
>> typeHandler=MyTypeHandler} *
>> foo = *#{some_column,
>> jdbcType=NUMERIC,
>> typeHandler=MyTypeHandler} *
>> WHERE
>> bar = *#{some_column,
>> jdbcType=NUMERIC,
>> typeHandler=MyTypeHandler} *
>> bar = *#{some_column,
>> jdbcType=NUMERIC,
>> typeHandler=MyTypeHandler} *
>> bar = *#{some_column,
>> jdbcType=NUMERIC,
>> typeHandler=MyTypeHandler} *
>> bar = *#{some_column,
>> jdbcType=NUMERIC,
>> typeHandler=MyTypeHandler} *
>> bar = *#{some_column,
>> jdbcType=NUMERIC,
>> typeHandler=MyTypeHandler} *
>> bar = *#{some_column,
>> jdbcType=NUMERIC,
>> typeHandler=MyTypeHandler} *
>> bar = *#{some_column,
>> jdbcType=NUMERIC,
>> typeHandler=MyTypeHandler} *
>> bar = *#{some_column,
>> jdbcType=NUMERIC,
>> typeHandler=MyTypeHandler} *
>>
>> I'm totally not sold on this solution, or if there's even a problem.
>>
>> As I've said already, I support the re-introduction of parameter elements
>> that will work something like the "parameterDef" approach above (but I agree
>> that it could just be called "parameter").
>>
>> Clinton
>>
>>
>> On Thu, Feb 4, 2010 at 12:00 PM, Clinton Begin
>> <clinton.be...@gmail.com>wrote:
>>
>>> >> because an XML file should not be "formatting-sensitive".
>>>
>>> That's not true at all. The XML tags shouldn't be formatting sensitive,
>>> but the content can be. That's our format, that's our requirement.
>>>
>>> That said, I'm open to improving the error. But I personally will not
>>> support line breaks in the parameter structure.
>>>
>>> Clinton
>>>
>>>
>>> On Thu, Feb 4, 2010 at 9:03 AM, Marco Speranza <
>>> marco.speranz...@gmail.com> wrote:
>>>
>>>> Hi Clinton,
>>>>
>>>> So if the #{} syntax will never be removed we have to fix the little
>>>> line-break problem, because an XML file should not be
>>>> "formatting-sensitive".
>>>> Moreover yesterday night I made a simple test-case that reproduces the
>>>> example wrote in the iBatis manual (page 26), and the parser raises a
>>>> BuilderException (Improper inline parameter map format. Should be:
>>>> #{propName,attr1=val1,attr2=val2}).
>>>> So if your intention is maintaining this syntax, and you're open to fix
>>>> this problem, I can submit through Jira the patch needed I mentioned mails
>>>> ago in the same thread.
>>>> What do you think?
>>>>
>>>>
>>>>
>>>>
>>>> 2010/2/4 Clinton Begin <clinton.be...@gmail.com>
>>>>
>>>> These are all great thoughts. As I said, one of them is likely to be
>>>>> implemented in the future. It's just been deprioritized for now.
>>>>>
>>>>> Clinton
>>>>>
>>>>>
>>>>> On Thu, Feb 4, 2010 at 8:42 AM, Simone Tripodi <
>>>>> simone.trip...@gmail.com> wrote:
>>>>>
>>>>>> Yep, I forgot the same syntax is used in annotations :)
>>>>>> BTW, it was just a 2 cents idea, not a real proposal.
>>>>>> Cheers,
>>>>>> Simo
>>>>>>
>>>>>> http://people.apache.org/~simonetripodi/<http://people.apache.org/%7Esimonetripodi/>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 4, 2010 at 4:22 PM, Clinton Begin <
>>>>>> clinton.be...@gmail.com> wrote:
>>>>>> > The syntax will never be removed, first because it's the preferred
>>>>>> way of
>>>>>> > the majority, and second, because we need a parameter syntax that is
>>>>>> > compatible with other configuration options, like annotations or
>>>>>> JSON, etc.
>>>>>> >
>>>>>> > Clinton
>>>>>> >
>>>>>> > On Thu, Feb 4, 2010 at 12:44 AM, Simone Tripodi <
>>>>>> simone.trip...@gmail.com>
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> Hi all guys,
>>>>>> >> sorry but I explained my "2 cents idea" in the wrong way :P
>>>>>> >> Indeed, in my dreams, I'd completely _remove_ the #{} syntax, IMHO
>>>>>> it
>>>>>> >> should be simpler reading a 100% pure XML SQL map like:
>>>>>> >>
>>>>>> >> update ORDER_ENTRY.CONTACT
>>>>>> >> set
>>>>>> >> DEPT_ID = <parameter name="deptId" javaType="String"
>>>>>> jdbcType="VARCHAR"
>>>>>> >> />
>>>>>> >> STATE_ID = <parameter name="stateId" javaType="String"
>>>>>> jdbcType="VARCHAR"
>>>>>> >> />
>>>>>> >> TIME_ZONE_ID = <parameter name="timeZoneId" javaType="String"
>>>>>> >> jdbcType="VARCHAR" />
>>>>>> >>
>>>>>> >> instead of
>>>>>> >>
>>>>>> >> update ORDER_ENTRY.CONTACT
>>>>>> >> set
>>>>>> >> DEPT_ID = #{deptId, javaType=String, jdbcType=VARCHAR},
>>>>>> >> STATE_ID = #{stateId, javaType=String, jdbcType=VARCHAR},
>>>>>> >> TIME_ZONE_ID = #{timeZoneId, javaType=String, jdbcType=VARCHAR}
>>>>>> >>
>>>>>> >> even if, of course, for a simpler case like:
>>>>>> >>
>>>>>> >> insert into
>>>>>> >> users (
>>>>>> >> id,
>>>>>> >> username,
>>>>>> >> password)
>>>>>> >> values (
>>>>>> >> <parameter name="id"/>,
>>>>>> >> <parameter name="username"/>,
>>>>>> >> <parameter name="password"/>
>>>>>> >> )
>>>>>> >>
>>>>>> >> is much more verbose than:
>>>>>> >>
>>>>>> >> insert into
>>>>>> >> users (
>>>>>> >> id,
>>>>>> >> username,
>>>>>> >> password)
>>>>>> >> values (
>>>>>> >> #{id},
>>>>>> >> #{username},
>>>>>> >> #{password}
>>>>>> >> )
>>>>>> >>
>>>>>> >> Thoughts?
>>>>>> >> All the best,
>>>>>> >> Simo
>>>>>> >>
>>>>>> >> http://people.apache.org/~simonetripodi/<http://people.apache.org/%7Esimonetripodi/>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> On Thu, Feb 4, 2010 at 2:20 AM, Daryl Stultz <da...@6degrees.com>
>>>>>> wrote:
>>>>>> >> >
>>>>>> >> > On Wed, Feb 3, 2010 at 7:38 PM, Guy Rouillier <
>>>>>> guyr-...@burntmail.com>
>>>>>> >> > wrote:
>>>>>> >> >>
>>>>>> >> >> On 2/3/2010 3:54 PM, Daryl Stultz wrote:
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >>>
>>>>>> >> >>> I like this idea, though to keep things consistent, I would
>>>>>> just use
>>>>>> >> >>> "parameter" instead of "parameterDef".
>>>>>> >> >
>>>>>> >> > Right, I just made up parameterDef to indicate is was for
>>>>>> defining the
>>>>>> >> > parameter rather than using it. I'm pretty new to iBATIS, so I
>>>>>> haven't
>>>>>> >> > used
>>>>>> >> > <parameter> yet and didn't want to suggest an orthogonal usage of
>>>>>> it.
>>>>>> >> > --
>>>>>> >> > Daryl Stultz
>>>>>> >> > _____________________________________
>>>>>> >> > 6 Degrees Software and Consulting, Inc.
>>>>>> >> > http://www.6degrees.com
>>>>>> >> > mailto:da...@6degrees.com
>>>>>> >> >
>>>>>> >>
>>>>>> >>
>>>>>> ---------------------------------------------------------------------
>>>>>> >> To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
>>>>>> >> For additional commands, e-mail: user-java-h...@ibatis.apache.org
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
>>>>>> For additional commands, e-mail: user-java-h...@ibatis.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Marco Speranza <marco.speranz...@gmail.com>
>>>>
>>>
>>>
>>
>
>
> --
> Marco Speranza <marco.speranz...@gmail.com>
>
