On Mon, Nov 18, 2013 at 4:02 PM, John Chilton <chilton(a)msi.umn.edu> wrote:
On Mon, Nov 18, 2013 at 9:55 AM, Peter Cock
> On Mon, Nov 18, 2013 at 12:35 PM, Peter Cock <p.j.a.cock(a)googlemail.com>
>> 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').
I see, so my (dummy) primary file could just a small text file
saying "This is a BLAST protein database." or similar - and
that would let me reproduce the current behaviour?
The only possible downside I can see right now is wondering
what happens to existing histories containing old BLAST
databases created with the current code... but that will sort
itself out eventually with some user inconvenience.
Who is the composite file architect (for their thoughts)?