Add methods for db_query() and db_query_range() in the default query plugin

Can't we add a wrapper for db_result, too?

One use case would be to allow to write a pgsql query backend which can query against pgsql even you are on a mysql installation.
db_result wouldn't be availible on the pager plugin, too.

Views hasn't used pager_query in years. Views 2 gave up on it very early in its development cycle due to the inability to support offset + paging. It has always used db_query_range() since Views 2 was even a little bit functional.

The patch seems safe enough. I don't see a point in wrapping db_result -- at the moment, all uses of db_result are in individual handlers, and you run db_result on top of db_query anyway, so it seems unlikely there's anything to actually change there.

dereine if you have time to commit this before I do, feel free.

Okay for db_result:

There is a query plugin which allows to connect to pgsql additional. https://github.com/dereine/views_pgsql
But it needs his own pager plugin, because of this code in views_plugin_pager.inc

  function execute_count_query(&$count_query, $args) {
    $this->total_items = db_result(db_query($count_query, $args));
    if (!empty($this->options['offset'])) {
      $this->total_items -= $this->options['offset'];
    }

    $this->update_page_info();
    return $this->total_items;
  }

This patch allows to replace db_query but this still wouldn't work for this plugin, see https://github.com/dereine/views_pgsql/blob/master/views_pgsql_plugin_pa...

So here is a new version of the patch

Now that I've thought about what this means, upgrading this to major. Changing to a task to indicate the acceptance of the feature request and the desire to get it in.

Also this.

Committed to 6.x-3.x. Does not apply to 7.x -- needs porting.

Reassigning.

I'm wondering whether this is really needed in d7.

Porting isn' this easy.

Correct me if I'm wrong but...

The point of this patch is to provide slave server support.
Drupal 7 has this support by default, and there are no changes needed for Views.

Quoting http://drupal.org/node/310071:

A given connection key must have one or more targets. A target is an optional alternate database that may be used if available. If the requested target is not defined, the system will silently fall back to a target of "default", which must always be defined.

The primary use of targets is for master/slave replication. The "default" target is the master SQL server. One or more "slave" targets may then be defined. Queries that are flagged to try and use a slave server if available will attempt to access the "slave" target. If one is available, that connection will be opened (if it is not already) and the query will run against the slave server. If not, the query will run against the "default" (master) server instead. That allows for a transparent fallback, so code can be written to take advantage of a slave server if it is available but will still run without one with no modification.

I haven't used slave servers, so there might be additional changes needed for Views (allow the user to specify a "target" in the query options that we pass to db_select?) to use slave servers properly, but that change is not the one from the patch, there's no need to abstract out the query functions another time.

So... "fixed"?

> I haven't used slave servers, so there might be additional changes needed for Views (allow the user to specify a "target" in the query options that we pass to db_select?) to use slave servers properly, but that change is not the one from the patch, there's no need to abstract out the query functions another time.

There is another issue already which has a patch attached and it's need review or something like this.
Would like to hear the oppinion of earl and or q0rban.

I think it's safe to close this now.

A somehow better status

I don't think this needs to be 'fixed' for 7.