[BioSQL-l] Pg and mysql versions are decoupled

[Aaron J Mackey]

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
>

-- 
 Aaron J Mackey
 Pearson Laboratory
 University of Virginia
 (434) 924-2821
 amackey at virginia.edu