asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yingyi Bu <buyin...@gmail.com>
Subject Re: IFramewriter state transitions
Date Thu, 10 Dec 2015 16:32:45 GMT
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 since
> it has multiple inputs and a single output.
> This doesn't conform to the allowed calls as per the contract specified in
> 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’s not allowed.
> >> However, I don’t think that each implementation should check that, 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 added
> >> 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 exception
> >>> 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? If
> >>> 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 number
> >>>>> of
> >>>>> test failures - especially when testing error conditions. Ian has
> >>>>> written
> >>>>> up a document [1] on the current contract (which is unfortunately
not
> >>>>> consistently implemented) and on an alternate contract that we have
> >>>>> discussed.
> >>>>> We currently believe that the alternate contract would be preferable
> 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
found
> >>>>> and
> >>>>> fixed.
> >>>>>
> >>>>> Please take a look at the document and tell us, what you think about
> >>>>> the
> >>>>> contract and the approach.
> >>>>>
> >>>>> Thanks,
> >>>>> Abdullah, Ian, Yingyi, and Till
> >>>>>
> >>>>> [1]
> >>>>>
> >>>>>
> https://docs.google.com/document/d/1QJ8X7QFMMax5D5k9RVje6hoNr_SNZSW9Oshzv7DpcQw/edit?usp=sharing
> >>>>> [2] http://mockito.org/
> >>>>>
> >>>>>
> >>>>
> >>>>
> >
>

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