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>
