Hi, the following are the things that annoy me and that could be an improvement for the current BOGAS: 1/ SQL abstraction in perl We now use our own home grown BOGAS::DB::Rails module to remove simple queries and thus SQL language from the perl code: + no more mixing two languages + automatic retrieval of the result set and performing callbacks on the data removing all DB processing from the other modules. - we cannot do more complex things with the conditions (WHERE statement). Things like 'OR'ing a condition or automatic escaping of conditions that are given as a string are none existant and too complex to program ad-hoc. - we don't use the power of DBI to the fullest: we could escape all fields/values with DBI, now the possibility exists to not do this leading to non-escaped fields/values and thus a security risk (eventhough mod_sec would probably stop it). - it's a bit of a hassle to switch db connections. OO-ing the module would solve this problem. We could use SQL::Abstract for this purpose: + we can do complex things like escaping lists, giving 'OR' statements. - it's another syntax than what we currently use We could wrap SQL::Abstract into BOGAS::DB::Abstract and make our own OO version of this object with predefined query structures just like Rails provides now. But: - there is no real need as everything works. This is just an annoyance. Possible implementation time: 1 day. Even less. And: - we can take a step further by introducing a complete DB-abstraction cake-like instead of only SQL-abstraction. This means automatic database connection selection based on the table you're using and relations between tables already defined leading to automatic retrieval of all associated records. I actually already implemented this last year in august to have a WS as powerful as the cake-model, but initial tests had two disadvantages: - complex coding to define new relations (which I simplyfied, but making a change in that part of the code would probably take some time to get into 'the zone' again.) - initial tests showed this was rather slow. About 5x as slow for relationship heavy queries like GeneralQ. - we need documentation to let other people work with this. It's not as simple as simply doing some DBI stuff. + it already uses SQL::Abstract to make your queries but defaults to a cake-like syntax in giving the conditions and returning the result set. As an example, generalQ in AnnotDB.pm would be reduced from a wopping 1000+ lines to the following 62 lines with the DB-abstraction: http://psbdev01.fvms.ugent.be/trac/BOGAS/browser/branches/DBI/src/perl/modul... This would retrieve about all what AnnotDB::GeneralQ retrieves, even the external databases for protein domain en homologs, the prev/next gene in line, checking of GO labels, ... It's pretty neat. :) + this means we can drop a lot of long winding database retrieval code and use simple things like: BOGAS::DBI::Dynamic::Gene->new->search({ locus_id => $locus_id }); and get a hash with the database result. Or even BOGAS::DBI::Dynamic::Gene->new->get_context({ locus_id => $locus_id }); to simply get the prev and next gene. (And don't get annoyed by the syntax now, of course you could 'use BOGAS::DBI::Dynamic::Gene', make a new() object and don't call the class with it's fully qualified name as I'm doing above.) + In the above example I don't have to be concerned about setting the correct db-connection, table or relations, as this is all defined for us by simply calling the Gene-class. Possible implementation time: 1 week, probably more. this includes testing, converting old DBI code to this DBI-class code and documentation writing. My question is, mainly for those digging in the perl code: do we need anything like this? Am I now the only one being annoyed by how cumbersome we sometimes have to get information out of the DB? 2/ Tests We really need tests if we want asure that BOGAS works always on all tested aspects in all tested situations. + avoids bug hunting and late-bug reporting after we release a new production version. - takes time to implement and takes even more time to come up with all the tests. + But, as soon as we have something the bug-fix/test-writing cycle will improve. This means that for every bug discovered, a test is written to ensure the bug doesn't resurface after numerous other changes. Possible implementation time: 1 week, probably more. This is unpredictable. I don't even know how we should test the website for 'working' all the time. 3/ the blast: I know this is stepping on some toes, but the interface for blasting could be better. - I'm always confused where to click. There is no button sticking out (which would be the search button) and it's not located at the place you'd expect important buttons to be (right bottom). - I don't feel what the important, mandatory and optional parameters are. You get served with this option-rich form and I'm always glad I only have to c/p and press search. - what about a 'example blast', even if it is only to make testing easier? Anyway, Kenny -- ================================================================== Kenny Billiau Web Developer Tel:+32 (0)9 331 36 95 fax:+32 (0)9 3313809 VIB Department of Plant Systems Biology, Ghent University Technologiepark 927, 9052 Gent, BELGIUM kenny.billiau@ugent.be http://bioinformatics.psb.ugent.be ================================================================== "What we feel isn't important. The only question is what we do." -- Rohl