asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Till Westmann" <ti...@apache.org>
Subject Re: IFramewriter state transitions
Date Wed, 09 Dec 2015 19:48:46 GMT
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
View raw message