asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From abdullah alamoudi <bamou...@gmail.com>
Subject Re: IFramewriter state transitions
Date Wed, 09 Dec 2015 19:03:35 GMT
While thinking about this case, think about the case of an operator that
takes two inputs through two different 1 to 1 connections, hence they are
all in the same node and there will not be a network connector between them?

I am not sure how this works at the moment but I think that we need to
consider these cases.

~Abdullah.

Amoudi, Abdullah.

On Wed, Dec 9, 2015 at 10:56 AM, abdullah alamoudi <bamousaa@gmail.com>
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