apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bhupesh Chawda <bhup...@datatorrent.com>
Subject Re: Backward compatibility issue in 3.6.0 release
Date Mon, 15 May 2017 17:51:04 GMT
I also suggest going for 1.
But I think we should make variables private and provide protected getters
and setters.

~ Bhupesh


On May 15, 2017 23:18, "Bhupesh Chawda" <bhupesh@datatorrent.com> wrote:

Actually Ajay discovered this when upgrading the core dependency test.
One of the tests was failing.

~ Bhupesh


On May 15, 2017 23:15, "Pramod Immaneni" <pramod@datatorrent.com> wrote:

I would suggest going with 1.

Bhupesh how did you see this? Did it see it as part of working on an
operator in Malhar?

On Mon, May 15, 2017 at 9:53 AM, Vlad Rozov <v.rozov@datatorrent.com> wrote:

> Hi All,
>
> There is a possible change in operators behavior caused by changes that
> were introduced in the release 3.6.0 into DefaultInputPort and
> DefaultOutputPort. Please see https://issues.apache.org/jira
> /browse/APEXCORE-722. We need to agree how to proceed.
>
> 1. Break semantic versioning for the Default Input and Output Ports in the
> next release (3.7.0), declare protected variables as private and provide
> protected access method. Another option is to rename protected variables
to
> use less common names (for example __count).
> 2. Keep protected variables with the risk that the following common
> operator design pattern will be used accidentally by existing operators
and
> newly designed operators:
>
> public Operator extends BaseOperator {
>   private int count;
>   public DefaultInputPort in = new DefaultInputPort() {
>     @Override
>     public void process(Object tuple)
>     {
>        count++;  // updates DefaultInputPort count, not Operator count!
>     }
>   }
> }
>
>
> Thank you,
>
> Vlad
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message