From: "Jukka Zitting" <[EMAIL PROTECTED]>
> Gene Sokolov wrote:
> > it might be useful to consider an abstraction layer in 1.x
> > for adding other databases as well.
>
> Sounds nice. There "Broken Shinai" release (1.3) was the result of the
> first serious attempt towards database independence. It uses ODBC as a
> ready-made abstraction layer. The only problem was that the way Midgard
> handles the queries and returned rows is very slow with ODBC. I believe
> that this might be the issue also with other generic database
> abstraction layers.
That's not exactly what I meant. I was thinking more in terms of defining a
set of db-functions "the midgard way". I.e. an interface most suitable for
midgard needs. And then mapping those calls to native db libraries or odbc
calls. Making odbc the default db interface would certainly hurt
performance. Getting rid of odbc layer on freebsd (switching to freetds)
gave us about 10-15% performance boost with our mssql server.
> The "Broken Shinai" release didn't rewrite the SQL statements but
> achieved database independence at the library level. Rewriting SQL
> statements shouldn't be a big problem as all datatypes used by Midgard
> can quite easily be mapped to generic INT, STRING, DATE, and TEXT types
> that should be supported by all reasonable databases (Oracle port has a
> problem with TEXT fields being too small). The SET fields used in many
> tables can easily be converted to bitmaps stored in INT fields.
What are these smallint(5) types? Why 5? Is it an 80-bit unique id?
TEXT is rather short (< 32k) in postgresql too. And this limitation won't be
fixed for another couple of months. That might be a serius problem.
Gene Sokolov.
--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org
To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]
