On Mon, Nov 18, 2013 at 9:55 AM, Peter Cock <p.j.a.cock(a)googlemail.com> wrote:
On Mon, Nov 18, 2013 at 12:35 PM, Peter Cock
> 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.