Right now I have return; in views_optimized_views_pre_execute() commented out; in regards to the pager. I think hook_views_optimized_view_optimize could return something that controls if we want to force this to run even if the pager isn't used .

CommentFileSizeAuthor
#1 views_optimized-pager-1185260-1.patch1.17 KBmikeytown2

Comments

mikeytown2’s picture

mikeytown2 commented
Status: Active » Needs review
StatusFileSize
new views_optimized-pager-1185260-1.patch1.17 KB
fabianx’s picture

fabianx commented
Status: Needs review » Needs work

Hi,

Thanks for the patch. While I like the approach, I think we can do better.

I think the following things should be done here:

* return an array with information
** which also includes the functions to call for _get_orderby, _get_fields, which removes the redundant checks in the hooks.

In that information array have the level of optimization set (all queries, only with pager, etc.) with the maximum winning, and also allow modules to override the default of 1000 rows as there may be queries, which can be optimized and be faster even with 10000 rows or more.

This could look like:

  function mymodule_views_optimized_view_optimize($view) {

    if ($view->name != 'events') {
      return;
    }

    $info = array();

    $info[] = array(
      'get_subquery_fields' => 'mymodule_views_optimized_get_fields',
      'get_subquery_orderby' => 'mymodule_views_optimized_get_orderby',
      /* ... other extendable functions ... */
      'optimize_level' => VIEWS_OPTIMIZED_ALL_QUERIES,
      'max_pager_rows' => 1000
    );

    return $info;
}

Thoughts? Would that API work and be flexible enough?

Best Wishes,

Fabian

mikeytown2’s picture

mikeytown2 commented

Why call another set of functions? Have this all in one hook, and pass back the field and order by info. Also different views displays can have different filters, so adding a secondary filter on $view->current_display in the examples might be a good idea.