You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Marco Speranza <ma...@gmail.com> on 2010/02/02 15:13:46 UTC
Mapper parsing problem
Hi all Guys,
we have found a little problem on iBatis3.
We have create a xml mapper file with this query:
<update id="myUpdate" parameterType="MyBean" flushCache="true">
UPDATE TAB
<set>
<if test="id != null"> ID = #{id}, </if>
<if test="desc != null"> DESC = #{desc, jdbcType=TIMESTAMP,
typeHandler=SqlTimestampAsLongTypeHandler}, </if>
</set>
WHERE
...
</update>
where SqlTimestampAsLongTypeHandler is an our type handler.
if there is a TAB character or a NEW LINE character between javaType and
typeHandler parameter, the type handler is ignored.
thanks all
--
Marco Speranza <ma...@gmail.com>
Re: Mapper parsing problem
Posted by Clinton Begin <cl...@gmail.com>.
This was actually a very serious consideration for us. I personally like
this design a lot.
FWIW: Parameter maps are in iBATIS 3, but the DTD disables the element.
Primary reason is that it still works exactly like iBATIS 2, which is not
based on named parameters as you've suggested. Before adding it back, I
want to ensure that it works this way, but it's a bit of work to get it
there.
Clinton
On Wed, Feb 3, 2010 at 1:54 PM, Daryl Stultz <da...@6degrees.com> wrote:
>
>
> On Wed, Feb 3, 2010 at 3:32 PM, Simone Tripodi <si...@gmail.com>wrote:
>
>> Forgot to say that, of course, there are cons, like in the sample below:
>>
>> I misread your first post and was thinking you wanted something like this:
>
> <insert id=”insertUser” parameterType=”User” >
> <parameterDef name="department" mode="OUT" jdbcType="CURSOR" javaType="Department"
> resultMap="departmentResultMap"/>
> insert into users (id, username, password, department)
> values (#{id}, #{username}, #{password}, #{department})
> </insert>
>
> I'm totally mixing your examples up, but the point is "parameterDef" just
> defines the nature of the parameter, #{department} just applies the value in
> the right spot. Maybe that's worse, I don't know!
>
> --
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:daryl@6degrees.com
>
Re: Mapper parsing problem
Posted by Guy Rouillier <gu...@burntmail.com>.
One change I'd like to see in the mapper file is to allow any ordering
of clauses within a ResultMap. I've gotten tripped up twice because I
put an association clause in the middle of a bunch of result clauses.
Why would I want to do this? To keep the clauses in the same order as
the columns from the select. I don't see why the parser should care
about what order the clauses appear.
Thanks.
On 2/4/2010 2:00 PM, Clinton Begin 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.speranza79@gmail.com <ma...@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.begin@gmail.com
> <ma...@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.tripodi@gmail.com <ma...@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.begin@gmail.com <ma...@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.tripodi@gmail.com <ma...@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
> <daryl@6degrees.com <ma...@6degrees.com>> wrote:
> >> >
> >> > On Wed, Feb 3, 2010 at 7:38 PM, Guy Rouillier
> <guyr-ml1@burntmail.com <ma...@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:daryl@6degrees.com <ma...@6degrees.com>
> >> >
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> user-java-unsubscribe@ibatis.apache.org
> <ma...@ibatis.apache.org>
> >> For additional commands, e-mail:
> user-java-help@ibatis.apache.org
> <ma...@ibatis.apache.org>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> user-java-unsubscribe@ibatis.apache.org
> <ma...@ibatis.apache.org>
> For additional commands, e-mail:
> user-java-help@ibatis.apache.org
> <ma...@ibatis.apache.org>
>
>
>
>
>
> --
> Marco Speranza <marco.speranza79@gmail.com
> <ma...@gmail.com>>
>
>
--
Guy Rouillier
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Mapper parsing problem
Posted by Marco Speranza <ma...@gmail.com>.
Hi Clinton,
great! this is a good news ;-)
tnx very much
ciao
2010/2/14 Clinton Begin <cl...@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.speranza79@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 <cl...@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 <cl...@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.speranza79@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 <cl...@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.tripodi@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.begin@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.tripodi@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-ml1@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:daryl@6degrees.com
>>>>>>> >> >
>>>>>>> >>
>>>>>>> >>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> >> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>>>>>> >> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>>>>>> >>
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>>>>>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Marco Speranza <ma...@gmail.com>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Marco Speranza <ma...@gmail.com>
>>
>
>
--
Marco Speranza <ma...@gmail.com>
Re: Mapper parsing problem
Posted by Clinton Begin <cl...@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
<ma...@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 <cl...@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 <cl...@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.speranza79@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 <cl...@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.tripodi@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.begin@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.tripodi@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-ml1@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:daryl@6degrees.com
>>>>>> >> >
>>>>>> >>
>>>>>> >>
>>>>>> ---------------------------------------------------------------------
>>>>>> >> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>>>>> >> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>>>>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Marco Speranza <ma...@gmail.com>
>>>>
>>>
>>>
>>
>
>
> --
> Marco Speranza <ma...@gmail.com>
>
Re: Mapper parsing problem
Posted by Marco Speranza <ma...@gmail.com>.
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 <cl...@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 <cl...@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.speranza79@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 <cl...@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.tripodi@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 <cl...@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.tripodi@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-ml1@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:daryl@6degrees.com
>>>>> >> >
>>>>> >>
>>>>> >>
>>>>> ---------------------------------------------------------------------
>>>>> >> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>>>> >> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>>>> >>
>>>>> >
>>>>> >
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>>>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Marco Speranza <ma...@gmail.com>
>>>
>>
>>
>
--
Marco Speranza <ma...@gmail.com>
Re: Mapper parsing problem
Posted by Clinton Begin <cl...@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 <cl...@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.speranza79@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 <cl...@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.tripodi@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 <cl...@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.tripodi@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-ml1@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:daryl@6degrees.com
>>>> >> >
>>>> >>
>>>> >> ---------------------------------------------------------------------
>>>> >> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>>> >> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>>> >>
>>>> >
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>>>
>>>>
>>>
>>
>>
>> --
>> Marco Speranza <ma...@gmail.com>
>>
>
>
Re: Mapper parsing problem
Posted by Clinton Begin <cl...@gmail.com>.
>> 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
<ma...@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 <cl...@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 <si...@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 <cl...@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.tripodi@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-ml1@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:daryl@6degrees.com
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>> >> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>> >>
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>>
>>>
>>
>
>
> --
> Marco Speranza <ma...@gmail.com>
>
Re: Mapper parsing problem
Posted by Marco Speranza <ma...@gmail.com>.
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 <cl...@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 <si...@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 <cl...@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.tripodi@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-ml1@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:daryl@6degrees.com
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>> >> For additional commands, e-mail: user-java-help@ibatis.apache.org
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>
>>
>
--
Marco Speranza <ma...@gmail.com>
Re: Mapper parsing problem
Posted by Clinton Begin <cl...@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 <si...@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 <cl...@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.tripodi@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-ml1@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:daryl@6degrees.com
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> >> For additional commands, e-mail: user-java-help@ibatis.apache.org
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
Re: Mapper parsing problem
Posted by Simone Tripodi <si...@gmail.com>.
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/
On Thu, Feb 4, 2010 at 4:22 PM, Clinton Begin <cl...@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 <si...@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/
>>
>>
>>
>> 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 <gu...@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:daryl@6degrees.com
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Mapper parsing problem
Posted by Clinton Begin <cl...@gmail.com>.
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 <si...@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 <gu...@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:daryl@6degrees.com
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
Re: Mapper parsing problem
Posted by Simone Tripodi <si...@gmail.com>.
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/
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 <gu...@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:daryl@6degrees.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Mapper parsing problem
Posted by Daryl Stultz <da...@6degrees.com>.
On Wed, Feb 3, 2010 at 7:38 PM, Guy Rouillier <gu...@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:daryl@6degrees.com
Re: Mapper parsing problem
Posted by Guy Rouillier <gu...@burntmail.com>.
On 2/3/2010 3:54 PM, Daryl Stultz wrote:
>
>
> On Wed, Feb 3, 2010 at 3:32 PM, Simone Tripodi <simone.tripodi@gmail.com
> <ma...@gmail.com>> wrote:
>
> Forgot to say that, of course, there are cons, like in the sample below:
>
> I misread your first post and was thinking you wanted something like this:
>
> <insert id=”insertUser” parameterType=”User” >
> <parameterDef name="department" mode="OUT" jdbcType="CURSOR"
> javaType="Department" resultMap="departmentResultMap"/>
> insert into users (id, username, password, department)
> values (#{id}, #{username}, #{password}, #{department})
> </insert>
>
> I'm totally mixing your examples up, but the point is "parameterDef"
> just defines the nature of the parameter, #{department} just applies the
> value in the right spot. Maybe that's worse, I don't know!
I like this idea, though to keep things consistent, I would just use
"parameter" instead of "parameterDef". Note you can use formatting to
make statements a little more readable with today's iBATIS config. Here
is a partial example from a production XML file:
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},
...
Same approach works for inserts. Putting each parameter on a new line
makes reading a little easier, especially if you are including
additional attributes.
--
Guy Rouillier
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Mapper parsing problem
Posted by Daryl Stultz <da...@6degrees.com>.
On Wed, Feb 3, 2010 at 3:32 PM, Simone Tripodi <si...@gmail.com>wrote:
> Forgot to say that, of course, there are cons, like in the sample below:
>
> I misread your first post and was thinking you wanted something like this:
<insert id=”insertUser” parameterType=”User” >
<parameterDef name="department" mode="OUT" jdbcType="CURSOR"
javaType="Department"
resultMap="departmentResultMap"/>
insert into users (id, username, password, department)
values (#{id}, #{username}, #{password}, #{department})
</insert>
I'm totally mixing your examples up, but the point is "parameterDef" just
defines the nature of the parameter, #{department} just applies the value in
the right spot. Maybe that's worse, I don't know!
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:daryl@6degrees.com
Re: Mapper parsing problem
Posted by Simone Tripodi <si...@gmail.com>.
Forgot to say that, of course, there are cons, like in the sample below:
<insert id=”insertUser” parameterType=”User” >
insert into users (id, username, password)
values (<parameter name="id"/>, <parameter name="username"/>
<parameter name="password"/>)
</insert>
is much more verbose than:
<insert id=”insertUser” parameterType=”User” >
insert into users (id, username, password)
values (#{id}, #{username}, #{password})
</insert>
All the best ;)
Simo
http://people.apache.org/~simonetripodi/
On Wed, Feb 3, 2010 at 9:19 PM, Simone Tripodi <si...@gmail.com> wrote:
> Hi all,
> just my 2cents: even if I'm familiar with XML SQL maps, I've always
> found the property parameter a little confusing into iBatis, since
> adds a new syntax in the XML syntax, indeed I was a great fan of
> iBatis2 ParameterMap.
> IMHO a "nice to have" in the SQL map is something like:
>
> <parameter name="department" mode="OUT" jdbcType="CURSOR"
> javaType="Department" resultMap="departmentResultMap"/>
>
> instead of:
>
> #{department, mode=OUT, jdbcType=CURSOR, javaType=Department,
> resultMap=departmentResultMap}
>
> and the reasons are:
> 1) easier to read, text editors with syntax highlight simplify the
> visualization and no new syntax to learn;
> 2) IDEs that read DTDs could simplify SQLmaps coding, offering code-completion;
> 3) easier to parse, no more \r\n problems.
> What do you think about it?
> All the best,
> Simo
>
> http://people.apache.org/~simonetripodi/
>
>
>
> On Wed, Feb 3, 2010 at 6:16 PM, Marco Speranza
> <ma...@gmail.com> wrote:
>> Hi Clinton,
>> thanks for your reply, I understand that's a design choice but I sadly
>> noticed that when the property parameter contains a break line character,
>> iBatis raises a so generic error that I had to spend a lot of time to
>> understand what was the cause...
>>
>> So, yesterday I spent a good part of the night studying iBatis code to
>> create a patch that easily (1 line of code) add the support for break line
>> character, with testcases.
>> If you all are open to this suggestion, I'd more than happy to open a Jira
>> issue and attach the patch, please let me know!!!
>>
>> thank
>>
>> 2010/2/2 Clinton Begin <cl...@gmail.com>
>>>
>>> That is by design and will not change. I suggest that when formatting
>>> parameters, put the entire thing on a newline when necessary. It's
>>> far too unreadable if you spit them up.
>>>
>>> Clinton
>>>
>>> On 2010-02-02, Marco Speranza <ma...@gmail.com> wrote:
>>> > Hi all Guys,
>>> >
>>> > we have found a little problem on iBatis3.
>>> > We have create a xml mapper file with this query:
>>> >
>>> >
>>> > <update id="myUpdate" parameterType="MyBean" flushCache="true">
>>> >
>>> > UPDATE TAB
>>> > <set>
>>> > <if test="id != null"> ID = #{id}, </if>
>>> > <if test="desc != null"> DESC = #{desc, jdbcType=TIMESTAMP,
>>> > typeHandler=SqlTimestampAsLongTypeHandler}, </if>
>>> > </set>
>>> > WHERE
>>> >
>>> > ...
>>> >
>>> > </update>
>>> >
>>> >
>>> > where SqlTimestampAsLongTypeHandler is an our type handler.
>>> >
>>> > if there is a TAB character or a NEW LINE character between javaType and
>>> > typeHandler parameter, the type handler is ignored.
>>> >
>>> > thanks all
>>> >
>>> >
>>> >
>>> > --
>>> > Marco Speranza <ma...@gmail.com>
>>> >
>>>
>>> --
>>> Sent from my mobile device
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>>
>>
>>
>>
>> --
>> Marco Speranza <ma...@gmail.com>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Mapper parsing problem
Posted by Simone Tripodi <si...@gmail.com>.
Hi all,
just my 2cents: even if I'm familiar with XML SQL maps, I've always
found the property parameter a little confusing into iBatis, since
adds a new syntax in the XML syntax, indeed I was a great fan of
iBatis2 ParameterMap.
IMHO a "nice to have" in the SQL map is something like:
<parameter name="department" mode="OUT" jdbcType="CURSOR"
javaType="Department" resultMap="departmentResultMap"/>
instead of:
#{department, mode=OUT, jdbcType=CURSOR, javaType=Department,
resultMap=departmentResultMap}
and the reasons are:
1) easier to read, text editors with syntax highlight simplify the
visualization and no new syntax to learn;
2) IDEs that read DTDs could simplify SQLmaps coding, offering code-completion;
3) easier to parse, no more \r\n problems.
What do you think about it?
All the best,
Simo
http://people.apache.org/~simonetripodi/
On Wed, Feb 3, 2010 at 6:16 PM, Marco Speranza
<ma...@gmail.com> wrote:
> Hi Clinton,
> thanks for your reply, I understand that's a design choice but I sadly
> noticed that when the property parameter contains a break line character,
> iBatis raises a so generic error that I had to spend a lot of time to
> understand what was the cause...
>
> So, yesterday I spent a good part of the night studying iBatis code to
> create a patch that easily (1 line of code) add the support for break line
> character, with testcases.
> If you all are open to this suggestion, I'd more than happy to open a Jira
> issue and attach the patch, please let me know!!!
>
> thank
>
> 2010/2/2 Clinton Begin <cl...@gmail.com>
>>
>> That is by design and will not change. I suggest that when formatting
>> parameters, put the entire thing on a newline when necessary. It's
>> far too unreadable if you spit them up.
>>
>> Clinton
>>
>> On 2010-02-02, Marco Speranza <ma...@gmail.com> wrote:
>> > Hi all Guys,
>> >
>> > we have found a little problem on iBatis3.
>> > We have create a xml mapper file with this query:
>> >
>> >
>> > <update id="myUpdate" parameterType="MyBean" flushCache="true">
>> >
>> > UPDATE TAB
>> > <set>
>> > <if test="id != null"> ID = #{id}, </if>
>> > <if test="desc != null"> DESC = #{desc, jdbcType=TIMESTAMP,
>> > typeHandler=SqlTimestampAsLongTypeHandler}, </if>
>> > </set>
>> > WHERE
>> >
>> > ...
>> >
>> > </update>
>> >
>> >
>> > where SqlTimestampAsLongTypeHandler is an our type handler.
>> >
>> > if there is a TAB character or a NEW LINE character between javaType and
>> > typeHandler parameter, the type handler is ignored.
>> >
>> > thanks all
>> >
>> >
>> >
>> > --
>> > Marco Speranza <ma...@gmail.com>
>> >
>>
>> --
>> Sent from my mobile device
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>
>
>
>
> --
> Marco Speranza <ma...@gmail.com>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Mapper parsing problem
Posted by Marco Speranza <ma...@gmail.com>.
Hi Clinton,
thanks for your reply, I understand that's a design choice but I sadly
noticed that when the property parameter contains a break line character,
iBatis raises a so generic error that I had to spend a lot of time to
understand what was the cause...
So, yesterday I spent a good part of the night studying iBatis code to
create a patch that easily (1 line of code) add the support for break line
character, with testcases.
If you all are open to this suggestion, I'd more than happy to open a Jira
issue and attach the patch, please let me know!!!
thank
2010/2/2 Clinton Begin <cl...@gmail.com>
> That is by design and will not change. I suggest that when formatting
> parameters, put the entire thing on a newline when necessary. It's
> far too unreadable if you spit them up.
>
> Clinton
>
> On 2010-02-02, Marco Speranza <ma...@gmail.com> wrote:
> > Hi all Guys,
> >
> > we have found a little problem on iBatis3.
> > We have create a xml mapper file with this query:
> >
> >
> > <update id="myUpdate" parameterType="MyBean" flushCache="true">
> >
> > UPDATE TAB
> > <set>
> > <if test="id != null"> ID = #{id}, </if>
> > <if test="desc != null"> DESC = #{desc, jdbcType=TIMESTAMP,
> > typeHandler=SqlTimestampAsLongTypeHandler}, </if>
> > </set>
> > WHERE
> >
> > ...
> >
> > </update>
> >
> >
> > where SqlTimestampAsLongTypeHandler is an our type handler.
> >
> > if there is a TAB character or a NEW LINE character between javaType and
> > typeHandler parameter, the type handler is ignored.
> >
> > thanks all
> >
> >
> >
> > --
> > Marco Speranza <ma...@gmail.com>
> >
>
> --
> Sent from my mobile device
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
--
Marco Speranza <ma...@gmail.com>
Re: Mapper parsing problem
Posted by Clinton Begin <cl...@gmail.com>.
That is by design and will not change. I suggest that when formatting
parameters, put the entire thing on a newline when necessary. It's
far too unreadable if you spit them up.
Clinton
On 2010-02-02, Marco Speranza <ma...@gmail.com> wrote:
> Hi all Guys,
>
> we have found a little problem on iBatis3.
> We have create a xml mapper file with this query:
>
>
> <update id="myUpdate" parameterType="MyBean" flushCache="true">
>
> UPDATE TAB
> <set>
> <if test="id != null"> ID = #{id}, </if>
> <if test="desc != null"> DESC = #{desc, jdbcType=TIMESTAMP,
> typeHandler=SqlTimestampAsLongTypeHandler}, </if>
> </set>
> WHERE
>
> ...
>
> </update>
>
>
> where SqlTimestampAsLongTypeHandler is an our type handler.
>
> if there is a TAB character or a NEW LINE character between javaType and
> typeHandler parameter, the type handler is ignored.
>
> thanks all
>
>
>
> --
> Marco Speranza <ma...@gmail.com>
>
--
Sent from my mobile device
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org