Hi Clinton,
great! this is a good news ;-)
tnx very much
ciao
2010/2/14 Clinton Begin <clinton.be...@gmail.com>
> 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>
>>
>
>
--
Marco Speranza <marco.speranz...@gmail.com>
