changeConnection from hook_query_alter

That's why you need a reference to $this->connection. with a reference, yes we can.

Let's see what the bot thinks but I like it. Will try to get Crell's blessings.

Seems reasonable and useful to me.

I think the biggest concern I have with this is that any query class could be a driver specific implementation. See DatabaseConnection::Select for the logic behind this. So what happens when you have a SelectQuery_pgsql and switch the connection to an instance of DatabaseConnection_mysql? I can't imagine there being any change of that scenario ending well.

In core the only driver implementing SelectQuery_driver is PostgreSQL, and in contrib, Oracle and SQL Server have implementations as well.

I am also not sure that we should be using a return-reference pattern here. Rather we should be using a setConnection() method, I suspect. I'll have to sleep on it.

What's the use case where you need to change the connection object after the query is already created? You can run a query off of any connection object you want if it's your own query.

I share mikey_p's concern that this means you can easily setup situations where a query object is bound to an incompatible connection object; There's a reason that you create query objects off of the connection object. (Actually there's several, but this is one of them. :-) ) I need a better picture of why you'd want to do something so wacky here.

Unless there's a case for needing the connection object itself, I think I'd prefer a setConnection() method instead of a return-ref. It feels cleaner.

So I guess this is "needs more info".

db_set_active() still works much as it did before, and you can always run $db = Database::getConnection($key, $target); $db->query() if you don't want to change the "main" database. Manipulating the connection object in hook_query_alter will miss a whole lot of queries that are not built queries...

I think the answer to #8 is "don't do that", I don't see much of a use case for this outside site-specific situations, and in site-specific situations if we allow people to do something weird, they shouldn't blame us when weird turns to stupid. It seems like both options are here as patches, and I'm not sure what harm this will do.

+1 - see #814312: Add getConnection() to SelectQueryExtender (I really just need the connection() getter, but I'm familiar with the context of Doug's original request and am totally down with that as well).

This patch works for my use case (I just need to get the connection, don't need a reference to it). Not setting to RTBC, since I haven't tested the hook_query_alter usage...

Couldn't this also be accomplished with a quick custom controller class that gets hook_entity_info_alter()'ed in for taxonomy terms (for instance)? That's one of the advantages of having loading mechanisms be swappable.

I know that doesn't cover mikeryan's issue, but it seems a cleaner way of handling entity loading like Doug is talking about.

The fundamental problem is that entity loading is just one example and already Mike Ryan has another example...

subscribe

sub.

My understanding is that this is still on the table for 7, as it effectively blocks one from doing any slave targeting in hook_query_alter(). Feel free to switch back if that has changed. :)

I would like to unsubscribe please. :)

FYI:
I started by using this patch to be able to change the database connection in the query alter but instead I just ended up implementing a SelectQueryExtender and changing the connection in the constructor of the extender class.

@q0rban that was a cross post.

But I'll leave it at 8.x for now, since you can change the connection object if you implement an extender.

Yes, but still somewhat of a bug (IMO) in 7.

@q0rbon - the process is to fix bugs in 8.x and then consider backport. So bugs are always filed against 8.x first.

Ok, thanks for the clarification. :)

If this is "won't fix" we should probably explain why. It's a feature request so I see no reason to close without explanation.

Because Drupal is a democracy: we can do whatever with DBTNG whatever Crelll agrees to. He said don't do this so we are not. Basically he is fond of protected and heaven forbid we remove one.

http://drupal4hu.com/node/293 is a better answer.

that explanation does not apply. migrate module needs this and migrate is used by many sites. they should not all have to hack core.

Why does migrate need to create a query object off of one database and then mutate it to use another later? There's absolutely nothing preventing it from doing:

$result = Database::getConnection('db1')->select($table)->...->execute();

$conn =   Database::getConnection('db2');
foreach ($result as $record) {
  $conn->insert($table)->...->execute();
}

The support for directly fetching a given connection object and reusing it (rather than having to play with db_set_active()) was specifically intended for use cases like migrate that need to play with multiple databases simultaneously.

We are using this to redirect all select queries to the slave database. How would one accomplish that without this patch and without hacking core?

function example_query_alter(QueryAlterableInterface $query) { 
  if (get_class($query) == 'SelectQuery') {
    $connection = &$query->connection();
    $connection->setTarget("slave");
  }
}

Updated patch attached.

Ok, ericduran helped me find a way around without needing to hack core or use the above patch:

class SlaveTarget extends SelectQueryExtender {
  public function __construct(SelectQueryInterface $query, DatabaseConnection $connection) {
    if ($connection->getTarget() != 'slave') {
      $connection = Database::getConnection('slave', $connection->getKey());
    }
    parent::__construct($query, $connection);
    $this->addTag('SlaveTarget');
  }
}

/**
 * Implements hook_query_alter().
 */
function example_query_alter(QueryAlterableInterface $query) { 
  if (is_a($query, 'SelectQuery') && !$query->hasTag('SlaveTarget')) {
    $query->extend('SlaveTarget');
  }
}

Do folks implementing ericduran's solution (posted here and on drupal.stackexchange.com) have it working on more recent releases of Drupal 7 (7.15 or 7.16)?

I've created a custom module with his code and have confirmed that the function and class are both running via dpm() debugging messages, but the devel query log still shows that all the queries are sent to the 'default' database. I also played around with the module weight and the 'bootstrap' field to make sure that the custom code runs in time, but no dice there either.

I can see in the query log that Views queries are sent to the 'slave' when I select a view to use the "Use Slave Server" option so I know that there is a valid connection to the slave, but I can't seem to get this method to work for the bulk of SELECT queries that are running. suggestions?

edit: fwiw, the core patch in #35 doesn't work for me in 7.16 either

Pretty sure this is a non-starter now.