I may not have been clear below. Using $db->query() is just as secure as using db_query(). The security handling happens much further down in the system. db_query() is now basically a dumb convenience wrapper that has really only one line of value in it (once the BC layer is removed). --Larry Garfield On Fri, 22 Aug 2008 15:19:00 +0200, "Ernst Plüss" <ernst.pluess@gmail.com> wrote:
I'm just in the process of writing a osCommerce api for Drupal. I started my work by using db_set_active(). Unfortunaltey this only works as long there are now problems in the code. (Which of course shouldn't be the case for production).
Let's make an example:
db_set_active('oscommerce'); // read oscommerce data db_set_active();
If an error occurs during the oscommer data access the drupal DB is not found any more. You'll get error messeage telling you that table watchdog couldn't be found. I thing we should use the db_* methods because of security, but replacing the active DB isn't fail proof.
Best Regards Ernst
2008/8/22 Larry Garfield <larry@garfieldtech.com>
On Thursday 21 August 2008 10:21:37 pm Chris Johnson wrote:
Is it generally desirable that contributed modules use the Drupal database abstraction whenever possible when accessing external databases? That is, is it generally preferable to use db_query() and friends, instead of mysql_connect(), mysql_query(), etc. whenever possible?
Yes, very much so. All of the security system is built into the abstraction layer; using mysql_query() directly means you're totally on your own for security.
I'd especially like to chat with the folks working on the DB layer for D7. It would be nice to provide an interface to allow adding an additional DB programmatically from the contrib module.
..chris
Well hi there! :-)
What you describe was absolutely an issue in the D6 and earlier DB layer. The new DB layer is still not perfect, but has improved on it in two ways:
1) The $databases value is always an array. It can be a flattened array, as some layers are optional, but since the installer populates it in the first place it will in almost every case already be an array.
2) You can actually instantiate a connection object directly. I wouldn't recommend it as then the core system can't switch to it, but it's possible. :-)
3) (Nobody expects the Spanish Inquisition!) The db_*() functions are all dumb wrappers. You can grab a database connection with Database::getConnection($key) and then do everything after that with method calls; $db->query(), $db->insert(), $db->select(), etc. So if you want to use a given database connection and just pull yourself out of the Drupal "active database" definition entirely, you can do so.
It's still not perfect, though, I agree. If you have a suggestion for how to make the connection management more flexible without hurting performance (it is along the critical path, so we have to be careful) please post an issue. Just because the mega-patch landed doesn't mean we're done changing things yet. :-)
-- Larry Garfield larry@garfieldtech.com