Testing of genotypic data web services

[lmansueto]

Hello every one, I am about to complete implementing BRAPI calls for SNP-seek, to query genotypic, phenotypic and passport data for the 3024 rice genomes. My main concern is the huge genotype matrix if the entire matrix is queried. Aside from paging and tsv format, I have implemented several workarounds to handle memory constraints and improve response.

With this, do we have a common testing client (ex. flapjack) I can use to test compliance and performance, before I make it "officially" public ? The docs are here http://snp-seek.irri.org/swagger-brapi/index.html but as I said it still needs client testing especially for large queries. Thanks.

Loc

[imilne]

Could you elaborate on your concerns for the genotype matrix stuff?

You can certainly use Flapjack to test compliance and performance and we'd be happy to help with this. There should be a new release in a few days - but we need to look at some of the BrAPI issues again as it's not currently compliant with the evolved spec (and the public versions have never had BrAPI functionality exposed in them anyway).

Iain

[lmansueto]

I'm not familiar whats the maximum dimension flapjack can handle, but in any case every client has a maximum to handle (our maximum data dimension is 3k x 32M). Query and data transfer for large matrices takes time from minutes to hours, so user-interactivity is sacrificed. So I suppose a user downloads large data on first use, leave, and when done save the result locally, then use the local copy for future use. This is where the tsv format is appropriate. But suppose the query is large and the user is in "interactive-mode", if paging is not specified does this mean the server have to return all, which can take a long wait ? So I set a maximum number of records to return, and the client application needs to check the paging if all or just a subset was returned, then requery for the next pages if required. Thanks that you can assist and we can test these cases, both in the server and client side. Please keep me posted when ready.

Loc

[rfinkers]

This was touched upon in the last Hacklethon. Every server can set its maximum what to return in the JSON. Large datasets are only available via the .tsv downloads. Is this something to address with a statuscode in the JSON, saying "data to large, download the file otherwise "?

[jeback1]

Loc: Are you comfortable with Richards suggestion of returning a message saying that the user should use .tsv downloads for large data sets? If so, I would propose that we close this issue.

Thanks, Jan Erik

[imilne]

You could argue that if the server didn't want to support large downloads, then it shouldn't specify JSON as a supported response in the /calls details. However, that's on the assumption that BrAPI implementations are 'allowed' to have methods that never respond with JSON. It would also fail if you still wanted a server to allow JSON for small requests.

[BrapiCoordinatorSelby]

Closing this issue. This seems to be an implementation discussion, not an issue with the actual spec.

Please move any further implementation discussions like this to the Community Forum

If there are an updates to the spec you need to help support large data sets, please open a new issue.

Related to testing clients, BRAVA (built by IPK) is publicly available and is an excellent tool for basic testing. Also, I'm working on a use case based testing tool for doing more targeted testing. This is still under construction, but should be available soon.