Ah, no problem.  If you do leave out the annotation, the variables will
simply be named in order, like:  #{1}, #{2}, etc.
Clinton

2009/10/13 Tomáš Procházka <t.procha...@centrum.cz>

>
> No. I think that when I use XML, anotation is not necessary. This was my
> fault. Thanks you.
>
> ______________________________________________________________
> > Od: "Clinton Begin" <clinton.be...@gmail.com>
> > Komu: user-java@ibatis.apache.org
> > Datum: 13.10.2009 12:45
> > Předmět: Re: two parametr in Mapper method
> >
> >In your second XML example, are you still using the same method signature?
> >
> >Like this:
> >
> >List<Send> getAllItems(@Param("offset") int offset, @Param("limit") int
> >limit);
> >
> ><?xml version="1.0" encoding="UTF-8" ?>
> ><!DOCTYPE mapper PUBLIC "-//ibatis.apache.org//DTD Mapper 3.0//EN" "
> >http://ibatis.apache.org/dtd/ibatis-3-mapper.dtd";>
> ><mapper namespace="cz.apache.ibatis.SendMapper">
> >       <select id="getAllItemsX" parameterType="map"
> >resultType="cz.apache.ibatis.Send" >
> >               select * from send LIMIT #{offset}, #{limit}
> >       </select>
> >
> ></mapper>
> >
> >
> >Clinton
> >
> >2009/10/12 Tomáš Procházka <t.procha...@centrum.cz>
> >
> >>
> >> I tested it and it doesn't works for me.
> >>
> >> This works great now:
> >>
> >>        @Select({"SELECT * FROM send LIMIT #{offset}, #{limit}"})
> >>         List<Send> getAllItems(@Param("offset") int offset,
> @Param("limit")
> >> int limit);
> >>
> >> but this not:
> >>
> >> <?xml version="1.0" encoding="UTF-8" ?>
> >> <!DOCTYPE mapper PUBLIC "-//ibatis.apache.org//DTD Mapper 3.0//EN" "
> >> http://ibatis.apache.org/dtd/ibatis-3-mapper.dtd";>
> >> <mapper namespace="cz.apache.ibatis.SendMapper">
> >>        <select id="getAllItemsX" parameterType="map"
> >> resultType="cz.apache.ibatis.Send" >
> >>                select * from send LIMIT #{offset}, #{limit}
> >>        </select>
> >>
> >> </mapper>
> >>
> >>
> >> I got:
> >>
> >> Exception in thread "main" org.apache.ibatis.exceptions.IbatisException:
> >> ### Error querying database.  Cause:
> org.apache.ibatis.type.TypeException:
> >> JDBC requires that the JdbcType must be specified for all nullable
> >> parameters.
> >> ### The error may exist in SendMapper.xml
> >> ### The error may involve
> cz.apache.ibatis.SendMapper.getAllItemsX-Inline
> >> ### The error occurred while setting parameters
> >> ### SQL: select * from send LIMIT ?, ?
> >> ### Cause: org.apache.ibatis.type.TypeException: JDBC requires that the
> >> JdbcType must be specified for all nullable parameters.
> >>        at
> >>
> org.apache.ibatis.exceptions.ExceptionFactory.wrapException(ExceptionFactory.java:8)
> >>
> >>
> >> How Can I specify parametr types?
> >>
> >> ______________________________________________________________
> >> > Od: "Clinton Begin" <clinton.be...@gmail.com>
> >> > Komu: user-java@ibatis.apache.org
> >> > Datum: 06.10.2009 09:33
> >> > Předmět: Re: two parametr in Mapper method
> >> >
> >> >multiple parameters will require the XML equivalent parameter type to
> be
> >> >Map.  Behind the scenes, it will do exactly what you do today -- wrap
> >> >multiple params in a Map.  This keeps it simple and consistent.
> >> >Clinton
> >> >
> >> >On Mon, Oct 5, 2009 at 12:23 AM, Guy Rouillier <guyr-...@burntmail.com
> >> >wrote:
> >> >
> >> >> I'm glad to see you are considering allowing multiple parameters.
>  I've
> >> >> found having to bind everything into one is cumbersome.
> >> >>
> >> >> What are you thinking of doing for XML?  I'd suggest replacing
> >> >> ParameterType with ParameterList, with the latter a cut and paste
> from
> >> the
> >> >> mapper method.  Your example below would look like:
> >> >>
> >> >> parameterList="int offset, int limit"
> >> >>
> >> >> From a programmer's perspective, I'd find the cut and paste easy, and
> >> >> iBatis would have everything it needs to enable named parameters in
> the
> >> SQL.
> >> >>
> >> >> Clinton Begin wrote:
> >> >>
> >> >>> There's no way to introspect on the parameter names.
> >> >>> So your choices become:
> >> >>>
> >> >>> @Select({"SELECT * FROM send LIMIT #{1}, #{2}"})
> >> >>> List getAllItems(int offset, int limit);
> >> >>>
> >> >>> ...Or...
> >> >>>
> >> >>> @Select({"SELECT * FROM send LIMIT #{offset}, #{limit}"})
> >> >>> List getAllItems(@Param("offset") int offset, @Param("limit") int
> >> limit);
> >> >>>
> >> >>> Both suck. But we'll probably default to the first, and allow for
> the
> >> >>> second.
> >> >>> Gross.
> >> >>>
> >> >>> Clinton
> >> >>>
> >> >>> On Sun, Oct 4, 2009 at 8:00 PM, Guy Rouillier <
> guyr-...@burntmail.com
> >> <mailto:
> >> >>> guyr-...@burntmail.com>> wrote:
> >> >>>
> >> >>>    I'd be curious to understand what the Java limitation is.  I
> would
> >> >>>    have thought that with Java 1.5's support of varargs, limitations
> >> >>>    such as this would no longer exists.  Of course, to use varargs
> >> >>>    here, I suppose we'd have to use Object[], which would shoot your
> >> >>>    type safety.
> >> >>>
> >> >>>    Clinton Begin wrote:
> >> >>>
> >> >>>        It's a limitation in Java.  However, we are working on a
> couple
> >> >>>        of potential options.  But it's not possible to do it the way
> >> >>>        you've written it (which is really sad, because it's
> perfectly
> >> >>>        possible in C# and other languages).
> >> >>>
> >> >>>        Clinton
> >> >>>
> >> >>>        2009/10/4 Tomáš Procházka <t.procha...@centrum.cz
> >> >>>        <mailto:t.procha...@centrum.cz> <mailto:
> t.procha...@centrum.cz
> >> >>>        <mailto:t.procha...@centrum.cz>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>           Why not supported this?
> >> >>>
> >> >>>           @Select({"SELECT * FROM send LIMIT #{offset}, #{limit}"})
> >> >>>            List getAllItems(int offset, int limit);
> >> >>>
> >> >>>
> >> >>>           Its limitation of Java or bug in actual version?
> >> >>>
> >> >>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>>           To unsubscribe, e-mail:
> >> >>>        user-java-unsubscr...@ibatis.apacheorg
> >> >>>        <mailto:user-java-unsubscr...@ibatis.apache.org>
> >> >>>           <mailto:user-java-unsubscr...@ibatis.apache.org
> >> >>>        <mailto:user-java-unsubscr...@ibatis.apache.org>>
> >> >>>
> >> >>>           For additional commands, e-mail:
> >> >>>        user-java-h...@ibatis.apache.org
> >> >>>        <mailto:user-java-h...@ibatis.apache.org>
> >> >>>           <mailto:user-java-h...@ibatis.apache.org
> >> >>>        <mailto:user-java-h...@ibatis.apache.org>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>    --    Guy Rouillier
> >> >>>
> >> >>>
> >> >>>
> >>  ---------------------------------------------------------------------
> >> >>>    To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
> >> >>>    <mailto:user-java-unsubscr...@ibatis.apache.org>
> >> >>>    For additional commands, e-mail:
> user-java-h...@ibatis.apache.org
> >> >>>    <mailto:user-java-h...@ibatis.apache.org>
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >> >> --
> >> >> Guy Rouillier
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> 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
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
> For additional commands, e-mail: user-java-h...@ibatis.apache.org
>
>

Reply via email to