Aaron Stone wrote:
Dan Weber <[EMAIL PROTECTED]> said:
Solution B:
I have been following libdbi very closely. libdbi is a database
abstraction layer in C. Its not bulky like odbc, and its quite like the
perl DBI. Basically a move to a single driver libdbi would make sense
because you wouldn't have to rebuild to switch drivers.
[Goes to check out libdbi] ... libdbi looks very cool. We've already
basically written our own middle layer, so it would be pretty
straightforward to write a libdbi driver. I'm not sure if we would want to
retarget for libdbi and remove our own mid layer, though...
Because libdbi is LGPL and fairly small, it would be entirely reasonable
to simply put a version libdbi into the DBMail tree. That way, we don't
have to bother people with dependencies unless they already have a libdbi
and modules installation that we can hook into.
I have never used libdbi, but... We should not be dependent on a
database middle layer. Every database is different and maximum
performance is only gained by writing your SQL specifically for that
database.
What could make sense is to have a driver for the libdbi "database". So
we would support PostgreSQL, MySQL and libdbi, that way people could use
any database they wanted that has libdbi support, but we would not be
sacrificing our 1st class support of PostgreSQL and MySQL, and in fact
people can continue to write database server specific drivers (oracle
etc...).
I have asked a friend of mine (DBA), to review the sql layout for
dbmail. I can only say he will probably rewrite the whole sql schema
for performance. Maybe a new database layout for 2.1.
Sounds good, it will be interesting to see what he suggests.
So will I.
