<div dir="ltr">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).<br>
<br>Let's make an example:<br><br>db_set_active('oscommerce');<br>// read oscommerce data<br>db_set_active();<br><br>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.<br>
I thing we should use the db_* methods because of security, but replacing the active DB isn't fail proof.<br><br>Best Regards<br>Ernst<br><br><br><div class="gmail_quote">2008/8/22 Larry Garfield <span dir="ltr"><<a href="mailto:larry@garfieldtech.com">larry@garfieldtech.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Thursday 21 August 2008 10:21:37 pm Chris Johnson wrote:<br>
> Is it generally desirable that contributed modules use the Drupal<br>
> database abstraction whenever possible when accessing external<br>
> databases? That is, is it generally preferable to use db_query() and<br>
> friends, instead of mysql_connect(), mysql_query(), etc. whenever<br>
> possible?<br>
<br>
</div>Yes, very much so. All of the security system is built into the abstraction<br>
layer; using mysql_query() directly means you're totally on your own for<br>
security.<br>
<div class="Ih2E3d"><br>
> I'd especially like to chat with the folks working on the DB layer for<br>
> D7. It would be nice to provide an interface to allow adding an<br>
> additional DB programmatically from the contrib module.<br>
><br>
> ..chris<br>
<br>
</div>Well hi there! :-)<br>
<br>
What you describe was absolutely an issue in the D6 and earlier DB layer. The<br>
new DB layer is still not perfect, but has improved on it in two ways:<br>
<br>
1) The $databases value is always an array. It can be a flattened array, as<br>
some layers are optional, but since the installer populates it in the first<br>
place it will in almost every case already be an array.<br>
<br>
2) You can actually instantiate a connection object directly. I wouldn't<br>
recommend it as then the core system can't switch to it, but it's<br>
possible. :-)<br>
<br>
3) (Nobody expects the Spanish Inquisition!) The db_*() functions are all<br>
dumb wrappers. You can grab a database connection with<br>
Database::getConnection($key) and then do everything after that with method<br>
calls; $db->query(), $db->insert(), $db->select(), etc. So if you want to<br>
use a given database connection and just pull yourself out of the<br>
Drupal "active database" definition entirely, you can do so.<br>
<br>
It's still not perfect, though, I agree. If you have a suggestion for how to<br>
make the connection management more flexible without hurting performance (it<br>
is along the critical path, so we have to be careful) please post an issue.<br>
Just because the mega-patch landed doesn't mean we're done changing things<br>
yet. :-)<br>
<font color="#888888"><br>
--<br>
Larry Garfield<br>
<a href="mailto:larry@garfieldtech.com">larry@garfieldtech.com</a><br>
</font></blockquote></div><br></div>