[Biojava-l] Re: [BioSQL-l] release preparation

[mark.schreiber at novartis.com]

We tracked down the error to the fact that the Hilmar Oracle version (no 
assertion is made about the complexity) uses CLOBs to store sequence while 
the Len Oracle (no assertion about simplicity etc) version uses LONGs to 
store sequence. The biojava support code seems to assume LONGs and 
strangely until very recently  the JDBC oracle dirver seems to let you 
write LONGs to CLOBs although the data that comes out again is completely 
munged.

It would be possible to modify the biojava adapters to check for LONG or 
CLOB and behaive appropriately but this would cause lots of maintenance 
problems later.

Given this situtation, unless some one complains very loudly, the biojava 
oracle adapters will be changed to assume CLOBs. Note: This means if you 
are using biojava and oracle and biosql now then it will break unless you 
adopts Hilmar's version. It will not cause any changes to biojava users of 
MySQL etc.

- Mark





Len Trigg <len at reeltwo.com>
04/18/2005 04:58 PM

 
        To:     Mark Schreiber/GP/Novartis at PH
        cc:     Hilmar Lapp <hlapp at gmx.net>, Biosql <biosql-l at open-bio.org>
        Subject:        Re: [BioSQL-l] release preparation



Mark Schreiber wrote:
> now, my bad! Agreed that from a SQL query perspective the schemas are 
the 
> same, one just has more complexity (if I can call it that) under the 
hood.

Indeed, the complexity is more to do with the complexity of installing
and understanding what's going on in all those files :-) (particularly
if you are not an oracle expert and have only been looking at the
BioSQL schemas for the other supported databases), and that's why I
did the simple version.  That's partly confirmed by the fact that the
bjia description of how to use the original schema is about 8KB, while
the description for the simple schema is about 1KB.  I'm all for
dumping the simple one if the barrier for entry for the original
schema is lowered (maybe it already has been).


> I would prefer to keep instructions for the less complex version up for 
> the time being as we are having difficulties getting biojava to work 
> seamlessly with the more complex version. This is almost certainly a 
> failing of biojava for which the oracle support seems to have been 
> compiled against the 'simple' schema not the 'complex schema'.

It certainly was only tested against the simple version, because
that's the only schema I had working when I wrote the Oracle support.
I am a little surprised that you are having major difficulties though,
since the original package has a compatibility layer that (supposedly)
presents the same schema as the simple version.


> I expect we will soon have biojava supporting your version and we can 
drop 
> the 'simple' schema. After all, there is not much point using oracle if 
> you don't make use of the features.

In my case, it was a matter of using Oracle because that was what was
already installed :-)


Cheers,
Len.