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 <[email protected]> wrote: > I think you're right. > > Cheers, > Abdullah. > > Amoudi, Abdullah. > > On Wed, Dec 9, 2015 at 11:48 AM, Till Westmann <[email protected]> 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 <[email protected]> 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/ >>>>> >>>>> >>>> >>>> >
