Re: [discuss] change mechanism of java chassis POJO consumerparamters mapping

[wjm wjm <zz...@gmail.com>]

in most times, customers can add one parameter in producer, but compatible
to old versions
in this time, we force customers must upgrade their consumers, it's too bad.

if map parameters by index, add any new parameter in a wrapper like
"QueryWrapper", a logic error will occur
but if map parameters by name, only add new parameters which
have duplicated name will cause the error

so i think, map by name still is better.



bismy <bi...@qq.com> 于2019年1月21日周一 下午3:28写道：

> I do not think your suggestion is a good idea, and I'd prefer not change
> it and remain the same.
>
>
> You problem comes from the semantics of the definition:
>    void method(QueryWrapper querys, int p2);
> For query parameter querys (type of QueryWrapper) do not mean one
> parameter, but many parameters based on it's structure, it a special
> grammar for POJO queries. So the client code can be:
>    void method(int x, int y, int p2)
> or
>    void method(int x, int y, int z, int p2)
>
>
> When you add a new name for QueryWrapper, it equals to you add a parameter
> for
>    void method(int x, int y, int p2) to void method(int x, int y, int z,
> int p2)
> and it's a change should be noticed that client should change the
> invocation code.
>
>
> Benefit for your suggestion is that users can add new parameters for an
> API, and I think this scenario is a CHANGE, and should change client code,
> but not adapt to it.
>
>
> And if you use parameter name to handle this, their will cause conflicts.
> For example, add an x for this method:
>    void method(QueryWrapper querys, int x, int y);
>
>
> And We need to consider other problems like name in
> @RequestParam("name1")  is different with parameter name.
>
>
> In conclusion, I prefer not to handle this scenario.
>
>
> ------------------ 原始邮件 ------------------
> 发件人: "zzzwjm"<zz...@gmail.com>;
> 发送时间: 2019年1月18日(星期五) 凌晨0:17
> 收件人: "dev@servicecomb.apache.org"<de...@servicecomb.apache.org>;
>
> 主题: Re: [discuss] change mechanism of java chassis POJO consumerparamters
> mapping
>
>
>
> java8 support present interface method parameter name
> need to add compile argument, not debug option
>
> 在 2019年1月17日星期四，Willem Jiang <wi...@gmail.com> 写道：
>
> > Java compile will remove the parameters name by default. We faced the
> > same problem in CXF simple frontend.
> > The solution could be enable the debug option in the compiler or add
> > annotation to the parameters.
> >
> > If we decide to setting the option on the compiler, we should not only
> > throw exception in the runtime, but also document it.
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Thu, Jan 17, 2019 at 5:23 PM wjm wjm <zz...@gmail.com> wrote:
> > >
> > > Scenes：
> > > 1.producer is springMVC dev mode
> > >   class QueryWrapper {
> > >     int x;
> > >     int y;
> > >   }
> > >   void method(QueryWrapper querys, int p2);
> > >
> > >   will produce swagger operation, have 3 parameters: x, y, p2
> > >
> > > 2.consumer is POJO dev mode, declare a interface:
> > >   interface TestIntf {
> > >     void method(int x, int y, int p2);
> > >   }
> > >   until now, everything is ok.
> > >
> > > 3.producer upgrade
> > >   class QueryWrapper {
> > >     int x;
> > >     int y;
> > >     int z;
> > >   }
> > >   will produce swagger operation, have 4 parameters: x,y,z,p2
> > >
> > >   in this time, old POJO consumers will have problems:
> > >     assign x to x, y to y, p2 to z
> > >   that's because we map parameters by their index
> > >
> > > to resolve the problem:
> > >   we need to map parameters by their name
> > >   this require customers change their compile argument in pom.xml to
> > allow
> > > interface present method parameter name
> > >   if did not add compile argument, SDK can throw exception, and print
> how
> > > to add the compile argument.
> > >
> > >   any idea?
> >