Multiple database support
justdave at syndicomm.com
Mon Sep 1 14:34:16 UTC 2003
On 9/1/2003 8:46 AM +0200, Jeroen Ruigrok/asmodai wrote:
> -On [20030901 03:52], David Miller (justdave at syndicomm.com) wrote:
>>It would be cool to describe each table as a hash in perl code, and provide
>>the column names, abstract types, and even some DB-specific data (with a
>>hash key prefixed with the name of the DB it's for). The database-specific
>>code for each database could then read from that hash, do what it needs to
>>for it to work on that Database, and go do it.
> Hmm, that could work yeah. Especially since the MySQL code uses an
> tinyint for what would normally just be a boolean datatype, which
> PostgreSQL supports. This would, given its function and use, be more
> correct than MySQL's tinyint. So I could understand something like:
> "isprivate" -> "boolean"
> which would map to tinyint on MySQL and boolean on PostgreSQL, PL/SQL
> supports a boolean as well (need to ask my DBAs if this is a wrapper
> datatype), and Sybase probably uses an smallint.
Yep, that's the idea. Sybase has "bit".
FWIW, Sybase has "identity" which is a loose equivalent to MySQL's
"auto_increment", however, Sybase's implementation sucks. We would up
creating a separate table with a list of tables and key numbers, and
lock/incremenet/unlock the given row in that table when we need a new key.
>>It may even be possible to describe necessary changes that way, too, but
>>that might be more difficult (for the seamless upgrade stuff).
> Which reminds me, the schema's use of names isn't quite consistent,
> sometimes you see isblah, then is_blah, etc. Is there any desire to
> make the entire schema consistent? It would ease of administration,
> given you're not constantly thinking: "Was it isprivate or is_private?"
Yeah, there was talk of doing that at one point.
The main reason it hasn't been done yet is outlined in comment #1 on that bug.
Dave Miller Project Leader, Bugzilla Bug Tracking System
More information about the developers