On 2/27/06, Darrel O'Pry <dopry@thing.net> wrote:
On Mon, 2006-02-27 at 18:25 +0200, Adrian Rossouw wrote:
On 27 Feb 2006, at 6:11 PM, Darrel O'Pry wrote:
with 1) you may get slightly better performance since you aren't constantly parsing strings, but you start making some major changes to drupal's db_abstraction layer.
How long before it makes sense to just use a third party db abstraction library ?
I'm not hot on the idea of re-inventing the wheel yet again.
Neither am I unless we can improve on the original. Do you have any that have been in mind that will work for drupal?
I think db_rewrite_url will be hard to find an equivalent for but I'm sure we can hack that in... I'd ideally want support for
1) mysql 2) postgresql 3) oracle 4) db2 5) sqlite
features I'd like to see are 1) replication/cluster support 2) query result caching 3) transaction support
I think we are going overboard here. Support in core for all these bells and whistles is overkill. If this is pluggable, then I am not against it, but to be a standard feature, even for shared hosts, then I am. As for a db abstraction layer, I am conflicted on this. - It creates an external dependancy (e.g. PEAR DB) - We may be able to bundle it to get over this. - Remember the xmlrpc fiasco? We relied on something external, then had security issues, and re-wrote it inhouse. On the other hand: - Why reinvent the wheel? - NIH (Not invented here)? - We can do with better support for other databases, e.g. SQLite, better support for PostgreSQL, and whatever will happen because of the Inno/Sleepcat/Oracle thing.