Mailing-List: contact dev-help@asterixdb.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAOQkTyM+s0R_gkMrqjN89fj9mPzPZJQmi5GCmkCKa==BSWEwVA@mail.gmail.com>
References: <EC47AF55-44A4-4172-91ED-E4E8D43EC3BC@apache.org>
	<5667DEAC.1040309@gmail.com>
	<CAOQkTyM+fmmxBNEZmdb3mYsSBoaFACrmBTYEAYt01ED0pB9b4Q@mail.gmail.com>
	<69E10FC8-6E3E-4517-BA9E-11D160F5C947@apache.org>
	<CAOQkTyNfWLMV3k_4L=Kdms7=xvYU+tCndH4oOEe1pb-1XQ+aag@mail.gmail.com>
	<CAOQkTyM+s0R_gkMrqjN89fj9mPzPZJQmi5GCmkCKa==BSWEwVA@mail.gmail.com>
Date: Thu, 10 Dec 2015 08:32:45 -0800
Message-ID: 
 <CALjEsF7bfKz-Hytn5v7KfK5r0Q+zxuT+3ORSwzEUode4pvVLhg@mail.gmail.com>
Subject: Re: IFramewriter state transitions
From: Yingyi Bu <buyingyi@gmail.com>
To: dev@asterixdb.incubator.apache.org
Content-Type: multipart/alternative; boundary=94eb2c076a24b77ee005268dc1fb

--94eb2c076a24b77ee005268dc1fb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

There are multiple IFrameWriters created by the IOperatorNodePushable, one
for each input.
It doesn't violate the contract.

Best,
Yingyi

On Thu, Dec 10, 2015 at 7:55 AM, abdullah alamoudi <bamousaa@gmail.com>
wrote:

> However,
> Have a look at UnionAllOperatorDescriptor. For the IFrameWriter created
> here, it needs to accept multiple open calls and multiple close calls sin=
ce
> it has multiple inputs and a single output.
> This doesn't conform to the allowed calls as per the contract specified i=
n
> the document.
>
> Cheers,
> Abdullah.
>
> Amoudi, Abdullah.
>
> On Wed, Dec 9, 2015 at 11:52 AM, abdullah alamoudi <bamousaa@gmail.com>
> wrote:
>
> > I think you're right.
> >
> > Cheers,
> > Abdullah.
> >
> > Amoudi, Abdullah.
> >
> > On Wed, Dec 9, 2015 at 11:48 AM, Till Westmann <tillw@apache.org> wrote=
:
> >
> >> I think that the state diagram says that it=E2=80=99s not allowed.
> >> However, I don=E2=80=99t think that each implementation should check t=
hat, as
> >> that would require additional state and code in each operator that
> should
> >> not be needed (if everybody sticks to the contract).
> >> If we want to check that the contract is maintained we should do that
> >> either in the unit tests or by introducing a wrapper that checks the
> >> contract on top of the operator itself. This wrapper could then be add=
ed
> >> during plan generation if indicated by a user (e.g. by setting a flag)=
.
> >>
> >> My 2c,
> >> Till
> >>
> >> On 9 Dec 2015, at 10:56, abdullah alamoudi wrote:
> >>
> >> There seems to be something missing here which is the legal function
> calls
> >>> that can be made in each state. For example:
> >>>
> >>> 1. Is it legal to call open() on an open instance of IFrameWriter? If
> >>> not,
> >>> then is it the responsibility of the IFrameWriter to throw an excepti=
on
> >>> in
> >>> that case
> >>> ?
> >>> 2. Is it legal to call close() on a closed instance of IFrameWriter? =
If
> >>> not, then again, who's responsibility is it to throw an exception in
> that
> >>> case?
> >>> 3. Is it legal to call fail() on a failed instance of IFrameWriter? I=
f
> >>> not,
> >>> then again, who's responsibility is it to throw an exception in that
> >>> case?
> >>>
> >>> I am asking this because I think that is happening in some places in
> the
> >>> code already.
> >>> Should we allow that?
> >>>
> >>> Abdullah.
> >>>
> >>> Amoudi, Abdullah.
> >>>
> >>> On Tue, Dec 8, 2015 at 11:56 PM, Mike Carey <dtabass@gmail.com> wrote=
:
> >>>
> >>> +1
> >>>>
> >>>> On 12/8/15 5:43 PM, Till Westmann wrote:
> >>>>
> >>>> Hi,
> >>>>>
> >>>>> When improving test coverage we noticed, that there are some
> >>>>> inconsistencies wrt. state management and transitions in different
> >>>>> implementations of IFramewriter. These inconsistencies cause a numb=
er
> >>>>> of
> >>>>> test failures - especially when testing error conditions. Ian has
> >>>>> written
> >>>>> up a document [1] on the current contract (which is unfortunately n=
ot
> >>>>> consistently implemented) and on an alternate contract that we have
> >>>>> discussed.
> >>>>> We currently believe that the alternate contract would be preferabl=
e
> as
> >>>>> there is more similarity in the approach to handling errors during
> >>>>> open()
> >>>>> or nextFrame().
> >>>>> Our proposal is to
> >>>>> 1) Adopt the alternate contract and document it in
> >>>>> a) the IFramewriter javadoc and
> >>>>> b) a design document.
> >>>>> 2) Implement new operators according to the alternate contract.
> >>>>> 3) Add mock-based unit tests (e.g. using Mockito [2]) for new
> operators
> >>>>> that verify that the contract is maintained.
> >>>>> 4) Add mock-based using test for existing operators as bugs are fou=
nd
> >>>>> and
> >>>>> fixed.
> >>>>>
> >>>>> Please take a look at the document and tell us, what you think abou=
t
> >>>>> the
> >>>>> contract and the approach.
> >>>>>
> >>>>> Thanks,
> >>>>> Abdullah, Ian, Yingyi, and Till
> >>>>>
> >>>>> [1]
> >>>>>
> >>>>>
> https://docs.google.com/document/d/1QJ8X7QFMMax5D5k9RVje6hoNr_SNZSW9Oshzv=
7DpcQw/edit?usp=3Dsharing
> >>>>> [2] http://mockito.org/
> >>>>>
> >>>>>
> >>>>
> >>>>
> >
>

--94eb2c076a24b77ee005268dc1fb--