On Mon, Nov 18, 2013 at 9:55 AM, Peter Cock firstname.lastname@example.org wrote:
On Mon, Nov 18, 2013 at 12:35 PM, Peter Cock email@example.com wrote:
On Sun, Nov 17, 2013 at 8:30 AM, John Chilton wrote:
With these change, I was able to write working functional tests for your tool using the template you outlined in the Trello card. ... I discovered no problems with auto_primary versus basic composite types here, just the things listed above.
Not for me though, even if I rename the masking "file" param to avoid the ambiguous "file" parameters ...
I find that changing the order of the <extra_files> tags in the test seems to alter the failure - which supports my hunch that something is scrambling the order of the extra files, so that it fails to compare the generated blastdb.phr with the provided four_human_proteins.fasta.phd
John's replies via Twitter:
@pjacock Hard to argue with @travisci but your makeblastdb test works unmodified on my box and I can reorder the extras. I'm still looking..
@pjacock Got it, you are overriding display_data in blast DB datatypes. This breaks much! Is how the test framework/API/etc access datasets.
There may be trouble ahead... the current display_data override is to give some meaningful output to the user when they click the "eye ball" icon for a BLAST database - rather than something unhelpful and scary like a blank page.
I didn't implement any of this composite dataset stuff so I am just guessing on best practices here, but is the right thing to do here switch from 'basic' to 'auto_primary_file' ? Just generate a file that just includes the content you want to display and set that as the primary file - I think this might be better practice than overriding display_data. If you want that file to a log if it is available that is fine, if files are uploaded an optional log could be available and you can provide a default fallback if unavailable in generate_primary_file/regenerate_primary_file. If you do insist on overriding display data, than you should at least allow fallback to what the super class would do if (filename and filename != 'index').
A more slick option would be to override display_data to run blastdbcmd live, but that means a run time dependency of the datatype definition on (a specific version of) the BLAST+ binaries
- which could be problematic.
I had considered capturing the makeblastdb stdout to a file as blastdb.log and having that as the (human viewable) primary file of a composite datatype - but that would cause trouble if and when I manage to support user uploaded BLAST databases.