[development] Demystifying $view->exposed_data

Dipen dipench at gmail.com
Sat Jun 4 14:59:21 UTC 2011


 I am badly stuck at this one, I am trying to convert a cron function to
batched drush execution to overcome memory limits etc. I could have gone for
queued cron execution but in my initial assessment I found batched drush
execution simpler. Anyways, I am using views_savedsearches to allow my users
to keep a tab on their exposed filters, since the data keeps coming in for
their criteria I am also using notifications_views_savedsearches (which
comes in the same package) to notify them if they have subscribed to their
saved searches. So All is good except the amount of content is huge for
hook_cron of notifications_views_savedsearches to process without memory
errors which prompted me to convert it into batched drush execution.

So I got to a good start and quickly deconstructed (almost)
the notifications_views_savedsearches_cron implementation into batch process
to be run by drush. Everything is fine, except that $view->execute() doesn't
return any result for my implementation but does yield results in the
original implementation. This is the place I am stuck, few things to note

1> $view Object just before calling $view->execute() is exactly same for
both implementations ( old cron and new batch worker process ), I ran a diff
couple of times. Please note that both functions have practically same code
except that I had to write couple of extra function to make batch work.
2> On further investigation found out that query and count query are same
too but args are different.

Am I wrong to assume that calling execute() on two identical view objects
can lead to different results? Atleast thats what I am experiencing? (There
is no additional processing on the view object, they are exactly same before
execute() is called on them)

On further investigation found out that the view object of my batch worker
process has $this->exposed_data empty and thats the reason for args to be
malformed and for query to returning empty result. I haven't been able to
find out much on why is exposed_data set in one view and not in other when
they were identical before calling execute() on them, looking at call stack,
I found out much of the query building and pre processing is done in
$this->build and $this->_build($key) and thats where $this->exposed_data is
bailing out on me.

Some of the debugged Arrays:

$args for the cron function (the one thats working) -
    [0] => drealty_property
    [1] => 0
    [2] => 100000000
    [3] => 0
    [4] => 0
    [5] => 39

$this->exposed_data returns a healthy array

One thats not working ( my batched execution $args) :

    [0] => drealty_property
    [1] =>
    [2] =>
    [3] =>
    [4] =>
    [5] =>
    [6] =>

$this->exposed_data doesn't return anything.

Code of both functions is almost same and the $view object just prior to
$view->execute() is exactly identical.

Has anyone faced anything similar? Could it be due to the batch API? I am
using drush_backend_batch_process() to process my batch. Everything else is
working except that my batch process doesn't have anything in $view->result.
I haven't been able to find where does $this->exposed_data get set.

Crux of code for both function is:

    $vs = views_savedsearches_load($subscription['sid']);  // Retrieving
exposed filter setting for the subscriber using helper function of

    $view_name = db_result(db_query("SELECT name FROM {views_view} WHERE vid
= %d", $vs->vid));

    $view = views_get_view($view_name);

    if (is_object($view) && is_object($vs)) {
      if ($view instanceof view) {

        // Apply $vs->filters

        // The original code limits this value to 10 which is not much
useful as new data at any point of time is anytime more than 10
        $view->pager['items_per_page'] = 0;

        // Run the query   // $view at this point in both functions is
exactly same ( did a diff )

         $view->result  is empty for my batch process but has values for the
old cron function. I am pretty sure(?), that I am not making a silly
variable in scope mistake.

  Thanks in Advance

Dipen Chaudhary
QED42 : We build beautiful and scalable web strategies ( www.qed42.com )
Blog: dipenchaudhary.com
Twitter: http://twitter.com/dipench
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20110604/e740c409/attachment.html 

More information about the development mailing list