ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guy Rouillier <guyr-...@burntmail.com>
Subject Re: Mapper parsing problem
Date Thu, 04 Feb 2010 19:32:50 GMT
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 <mailto: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 <clinton.begin@gmail.com
>     <mailto:clinton.begin@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 <mailto: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 <mailto: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 <mailto: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
>             <daryl@6degrees.com <mailto:daryl@6degrees.com>> wrote:
>              >> >
>              >> > On Wed, Feb 3, 2010 at 7:38 PM, Guy Rouillier
>             <guyr-ml1@burntmail.com <mailto: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 <mailto:daryl@6degrees.com>
>              >> >
>              >>
>              >>
>             ---------------------------------------------------------------------
>              >> To unsubscribe, e-mail:
>             user-java-unsubscribe@ibatis.apache.org
>             <mailto:user-java-unsubscribe@ibatis.apache.org>
>              >> For additional commands, e-mail:
>             user-java-help@ibatis.apache.org
>             <mailto:user-java-help@ibatis.apache.org>
>              >>
>              >
>              >
>
>             ---------------------------------------------------------------------
>             To unsubscribe, e-mail:
>             user-java-unsubscribe@ibatis.apache.org
>             <mailto:user-java-unsubscribe@ibatis.apache.org>
>             For additional commands, e-mail:
>             user-java-help@ibatis.apache.org
>             <mailto:user-java-help@ibatis.apache.org>
>
>
>
>
>
>     --
>     Marco Speranza <marco.speranza79@gmail.com
>     <mailto:marco.speranza79@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


Mime
View raw message