[BioSQL-l] Pg and mysql versions are decoupled

[Matthew Pocock]

Is it easier to go mysql->pg or pg->mysql, or something_sane -> both?

M

Aaron J Mackey wrote:
> The best way I can think of to keep transform.pl-like functionality around
> would be to (re)package the code as a CPAN module, and let it float in the
> community, separate from biosql (transform.pl becomes a simple wrapper
> script of DBIx::Schema::Transform or whatever it is).  I'm surprised
> there's not already something like this out there already (I looked, but
> didn't find anything).
> 
> Of course, whether we continue to use it or not is up to us.  I think our
> transform.pl script could become a little smarter and use a pg-sql.tmpl
> template and only fill in the bits it needs (leaving things like rules and
> views and other oddities alone).  But I don't have enough emotional
> investment to add that functionality myself.
> 
> But imagining the "one true frozen schema" that never has to again be
> transformed is just that, imagination ;)
> 
> -Aaron
> 
> On Tue, 18 Mar 2003, Hilmar Lapp wrote:
> 
> 
>>First, I got frustrated yesterday about the transfrom.pl script unable
>>to parse the latest mysql schema version, although it's really not too
>>special. What's really frustrating is that the RecDescent parse
>>apparently yields a truncated document tree in a silent fashion, and
>>I'm not going to debug Parse::RecDescent. I suspect the problem is that
>>the token DEFAULT interferes with an internal interpretation of a
>>DEFAULT rule.
>>
>>Second, I added the rules suggested by Yves Bastide to the Pg version
>>of the schema. As soon as we agree on marching towards schema freeze,
>>I'll then update the Pg mapping drivers of bioperl-db, and I honestly
>>hope that then Pg can become a first-class supported RDBMS for biosql.
>>It's just so much more powerful than MySQL. I tested the effect of the
>>rules in DBI statement return values. If the rules fire then the return
>>value is 0E0 instead of 1, which as a string also evaluates to TRUE in
>>perl, but can be tested against 0 (which will test true, unlike -
>>obviously - the value '1'). So, a 'failed' insert (that is, an insert
>>that would have failed if it had been permitted) can be easily and
>>relatively cleanly detected in code. This removes a serious obstacle
>>for using biosql under Pg in a way that causes minimal impact on the
>>existing codebase, and can be easily taken advantage of in other Bio*
>>projects too. Thanks for this tip Yves.
>>
>>I'm ending this email with the proposal to abandon the transform_sql.pl
>>script, unless someone is serious about debugging and fixing it. If we
>>were to continue using it, the CREATE RULE section from biosqldb-pg.sql
>>would have to be moved into a separate file. Any takers? Any votes?
>>
>>	-hilmar
>>
> 
> 


-- 
BioJava Consulting LTD - Support and training for BioJava
http://www.biojava.co.uk