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 18:56:18 GMT
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