[
https://issues.apache.org/jira/browse/THRIFT-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245736#comment-14245736
]
Jens Geyer edited comment on THRIFT-2886 at 12/14/14 12:08 AM:
---------------------------------------------------------------
If anybody has a good idea how we handle this without breaking the builds too
long, that would be helpful. The only idea I have is a bit complicated and
requires some near-time help from certain language maintainers:
1. commit only server code changes for all languages (at least those actively
tested)
2. commit the modifications in {{ThriftTest.thrift}}
3. implement and commit clients as we go
All steps except the third must be implemented, built and successfully tested
before we can move forward to the next step. We could comnbine step 1+2 but
this introduces potentially more pressure when the build fails. Client
implementation (last step) is less critical and may be delayed. Client calls
that are not implemented are not tested, but the also do not break the build.
Where I would need some help is to implement the server code for certain
languages. Fortunately that code is quite simple and boils down to something
like this:
{code:title="c# version"}
public byte[] testBinary(byte[] thing)
{
string hex = BitConverter.ToString(thing).Replace("-", string.Empty);
Console.WriteLine("testBinary(" + hex + ")");
return thing;
}
{code}
If anyone has a better idea how to handle this, please don't hesitate.
was (Author: jensg):
If anybody has a good idea how we handle this without breaking the builds too
long, that would be helpful. The only idea I have is a bit complicated and
requires some near-time help from certain language maintainers:
1. commit only server code changes for all languages (at least those actively
tested)
2. commit the modifications in {{ThriftTest.thrift}}
3. implement and commit clients as we go
All steps except the third must be implemented, built and successfully tested
before we can move forward to the next step. Client implementation (last step)
is less critical and may be delayed. Client calls that are not implemented are
not tested, but the also do not break the build.
Where I would need some help is to implement the server code for certain
languages. Fortunately that code is quite simple and boils down to something
like this:
{code:title="c# version"}
public byte[] testBinary(byte[] thing)
{
string hex = BitConverter.ToString(thing).Replace("-", string.Empty);
Console.WriteLine("testBinary(" + hex + ")");
return thing;
}
{code}
If anyone has a better idea how to handle this, please don't hesitate.
> Integrate binary type in standard Thrift cross test
> ---------------------------------------------------
>
> Key: THRIFT-2886
> URL: https://issues.apache.org/jira/browse/THRIFT-2886
> Project: Thrift
> Issue Type: Sub-task
> Components: Test Suite
> Reporter: Jens Geyer
>
> I propose to complete the half-hearted try to integrate the {{binary}} type
> into the test suite. We actually have a {{CrazyNesting}} struct defined, yet
> that structure is not used in any call. So we do test the code generation
> vis-รก-vis compileability, but we do not test whether or not the
> impleemntation actually works.
> Background info:
> http://stackoverflow.com/questions/27408710/python-thrift-binary-type-requires-encoding
> *Spec proposal:*
> {code}
> /**
> * Prints 'testBinary("%s")' where '%s' is a hex-formatted string of
> thing's data
> * @param binary thing - the binary data to print
> * @return binary - returns the binary 'thing'
> */
> binary testBinary(1: binary thing),
> {code}
> *Test case proposal:*
> The client sends a binary containing all 256 bytes (in arbitrary order) to
> the server and checks the returned binary data against the value sent to the
> server. If they do match exactly, the test counts as passed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
