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>
>>
>
>
