[Gusdev-gusdev] Re: [Fwd: Porting GUS to a Open SourceDB ?]

[Steve F. <sfi...@pc...>]

Giuseppe-

GUS uses Perl DBI and Java JDBC to interact with the database.

I just did a quick grep of the Perl code base.   There is one place 
where we use DBD.  It is in our DBAdmin toolset.   This toolset is 
released with GUS, but it is not considered "standard" gus.    However, 
 it is a nice toolset which provides a web display of things like:  who 
is using the db, what queries are running, what are the constraints on 
the tables, etc.   So, it would be nice if we eventually made it DBD 
independent.

Besides that, GUS does not depend directly on DBD.

The first step to porting GUS to other DBMSs is to identify what are the 
DBMS dependent parts.   One example is that GUS uses schema spaces.   In 
other words, tables are named:  schema.table.   I know that postgres 
supports this, but when we last looked mysql did not.

I don't think there are alot of dependencies, but, to find them we would 
need to do some research.

Steve

Giuseppe Jurman wrote:

>>Thanks Elisabetta,
>>
>>An important question would be also why PostgreSQL and not MySQL, the
>>latter appears to be evolved well and have now a good support to
>>transactions via InnoDB, etc. I am very inclined to use Gmod and chado
>>por our project, but would like to have a final check on the potential
>>of GUS before starting things.
>>    
>>
>
>ITC-irst has started a working group for a full open source version of
>GUS, so to allow the substitution of the Oracle database management
>system for data tables and relations within GUS with an open source
>solution. In principle we are not oriented to the substitution
>of Oracle with another specific DMBS.
>
>It might be worthwhile to consider the possibility to turn DB
>independent the whole object-related part of GUS and then choosing the
>suitable DB-dedicated driver depending on the user's system. The first
>(heavy) step towards this option requires to check the existing code
>looking for the Oracle-specific SQL, and then designing an ad-hoc
>strategy to transform into either a DBI (better) or into a DBD (here
>the choice of the DBMS becomes a constraint).
>
>An important issue, for us, is how to align the DBD portions of the
>code along the next releases of GUS. In this view, we see the need of
>a DBI-DBD separation really relevant.
>
>We would like to perform the Oracle-PostgreSQL conversion in the most
>automated way possible. Before, the Oracle proprietary SQL code has to
>be somehow moved to the upper Perl Object Layer level, or to a new
>Perl Object Layer.
>
>Comments welcomed
>
>
>Giuseppe Jurman
>Cersare Furlanello
>
>  
>