I have recently started using Drupal 7 and I am a bit disappointed to find that the views_get_view_result function in views 7.x-3.0-alpha1 isn't working as it used to in D6. I have a normal view setup to return a few fields, Node title, image path. When i use the views_get_view_result function and spit out the result with a dpr() or print_r() I am getting the following.

Array
(
    [0] => stdClass Object
        (
            [nid] => 2
            [file_managed_file_usage_uri] => public://employee_photos/guy3.jpg
            [node_title] => Ian Bobian
            [field_data_field_job_title_node_entity_type] => node
            [field_data_field_dept_node_entity_type] => node
            [field_data_field_fun_fact_node_entity_type] => node
        )

    [1] => stdClass Object
        (
            [nid] => 3
            [file_managed_file_usage_uri] => public://employee_photos/guy1.jpg
            [node_title] => Will Browser
            [field_data_field_job_title_node_entity_type] => node
            [field_data_field_dept_node_entity_type] => node
            [field_data_field_fun_fact_node_entity_type] => node
        )
)

All fields have this "node_entity_type" thing tacked onto the end of the key and have a value of "node"

In the views preview, while editing that view, the sql query is...

SELECT node.nid AS nid, file_managed_file_usage.uri AS file_managed_file_usage_uri, node.title AS node_title, 'node' AS field_data_field_job_title_node_entity_type, 'node' AS field_data_field_dept_node_entity_type, 'node' AS field_data_field_fun_fact_node_entity_type FROM  {node} node LEFT JOIN {file_usage} file_usage ON node.nid = file_usage.id AND file_usage.type = :views_join_condition_0 LEFT JOIN {file_managed} file_managed_file_usage ON file_usage.fid = file_managed_file_usage.fid WHERE (( (node.status = '1') AND (node.type IN ('employee')) )) LIMIT 10 OFFSET 0

You can see that all the fields are being queried as ('node' AS field_data_field_dept_node_entity_type). Which explains why node is being returned in the views_get_view_result() function.

Why is this function not getting the values anymore? Is this by design? Is there a new way of using this function?

CommentFileSizeAuthor
#15 1063418-post-execute.patch3.97 KBmerlinofchaos
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dawehner’s picture

Category: bug » support
Status: Active » Fixed

This is somehow by design of fieldapi. We can't really do something here.

The question is whether you really want the view results or just use them for theming.
If you just want to theme something please accept it and use formatters.

If you need the results to do somethign else you you can do is some coding work:
There is a flag in the fieldapi data integration called 'add fields to query'.

Therefore you have to implement hook_views_data_alter(&$data);

There is a table foreach field, so you have to set $data['field_foo']['entity_id']['add fields to query'] = TRUE
Then the field content get's added to the result. This is a very edge case and might result in multiple rows etc.
It's not recommended unless you really know what you do.

merlinofchaos’s picture

I want to stress what dereine said, that this is the design of field api, not Views. We tried very, very hard to get the field results into the actual query, but the design of field api makes this simply intractible. We can't do it.

Zachmo’s picture

Disappointing as this is, I can understand the difficulty of interacting with the new api. I appreciate the work that others have put into the new system. I do think it is important to be able to receive views results in raw data, this is something I used heavily in past drupal implementations. Perhaps as the new system matures others will be able to find a work around. That's the beauty of open source! Thanks again guys for your quick responses and all your hard work on this essential module.

dawehner’s picture

As damien suggested in another issue we could push the full entities into the results.

Not sure whether this might produce a big memory overhead, but should not because entities are all stdClasses.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Zachmo’s picture

Maybe a boolean argument to views_get_view_result that would allow pushing the full field entity?
Where was the other issue that this was brought up in?

giorgio79’s picture

Ouch, so then we cannot use this function to programmatically grab views results as an array, as described here at the moment in D7
http://www.pridedesign.ie/content/drupal-get-view-results-php-code

This module seems to be unmaintained as well:
http://drupal.org/project/views_php_array

Is there any way to programmatically and easily get a views array, or I have to go back to goold old sql?

merlinofchaos’s picture

We've recently added code that copies field api values to the result.

giorgio79’s picture

Fantastic, much appreciated.

kevinob11’s picture

Has this change been committed yet?

When I view $view->result the field api fields still show "node".

Thanks

Zachmo’s picture

This is AWESOME news! Please let us know when it is fully integrated and ready for production.

Thanks for all your hard work!

kevinob11’s picture

Status: Closed (fixed) » Active

Per #8 field api values should be getting copied into the $views->result object.

I am using 7.x-3.x-dev and I am still seeing "node" as the value for all field api fields.

Also in the $views->field['field_name'] object the field_alias value is "nid" for all field api fields.

I am working on a views highcharts plugin and these two differences from D6 make it difficult to pull raw data programmatically from the view and format it for input into the chart object.

Thanks for all the hard work on this.

merlinofchaos’s picture

The problem is that this doesn't happen until pre_render() and views_get_view_result() doesn't do any rendering.

So you're going to have to actually render the view to get this data. I'm not sure there's really much we can do about this.

merlinofchaos’s picture

Well. What we could theoretically do about this:

Add a post_execute() method, and then move views_handler_field_field::pre_render() to post_execute().

That might help a little.

merlinofchaos’s picture

Version: 7.x-3.0-alpha1 » 7.x-3.x-dev
Status: Active » Needs review
FileSize
3.97 KB

Try this.

kevinob11’s picture

I'm actually not using views_get_view_results(), just dpm on the view in my theme preprocess function, not sure if this should yield the same results as I have never used the get_results function.

This does make things a bit better, by moving the fields in the result set, though they are still in arrays with different structure. This is actually similar to what I was doing to prepare the data in my preprocess function for my theme. My concern was that doing this in my preprocess function seemed pretty hacky. If I can rely on that data structure not changing, then this handles my standard use case pretty well.

However my other concern is that the data architecture will change when using views group by. As I understand it the fields actually end up in the query when a group by is used, so the layout of the results will change (which seemed to be the case when I tested). I think group by isn't mature yet anyway, so on some level this currently doesn't matter, but since this is a charting plugin, once group by is mature, I forsee using it very heavily.

My understanding is limited, as this is my first views plugin, and I am definitely open to better methods of approaching this that will provide consistency across a number of use cases.

Any input would be appreciated, thanks.

merlinofchaos’s picture

It probably will, but there is honestly no way we can normalize it. We have the option of giving you the rendered data or the raw data, but if you want is to try to manipulate the raw data, that's not going to happen.

kevinob11’s picture

Just did some testing with groupby and it seems that it sets the field_alias for the field correctly (matching the result set) on fields that are in an aggregate function. With this in mind I'm thinking I can use the following logic to set the field value correctly...

if ($view->field[$field_name]->field_alias == 'nid'){
$field_value = $view->result['row']->_field_data['nid']['entity']->{$field_name}['und']['0']['value'];
}
else {
$field_alias = $view->field[$field_name]->field_alias;
$field_value = $view->result['row']->{$field_alias};
}

This should catch the FAPI fields with the first statement and everything else with the second.

I will need to check if this breaks the nid field handler (I'm not sure what the field_alias is for it), but other than that is there any glaring issue with how this will retrieve the raw data for each field?

Thanks

kevinob11’s picture

Status: Needs review » Closed (fixed)

Nevermind, I just saw that issue queue regarding forcing views to put fields into the query. I will work from there. Thanks.

merlinofchaos’s picture

Status: Closed (fixed) » Needs review

Hey wait, let's not throw away my patch here.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

This seems to work pretty fine here.

kevinob11’s picture

Worked well for me.

merlinofchaos’s picture

Status: Reviewed & tested by the community » Fixed

Okay, committed.

Zachmo’s picture

Heyo...

My patch failed on Hunk 2.

patch -p1 < 1063418-post-execute.patch 
patching file includes/handlers.inc
Hunk #1 succeeded at 507 (offset 15 lines).
Hunk #2 FAILED at 1112.
1 out of 2 hunks FAILED -- saving rejects to file includes/handlers.inc.rej
patching file includes/view.inc
patching file modules/field/views_handler_field_field.inc
Hunk #1 succeeded at 489 (offset -15 lines).
Hunk #3 succeeded at 575 (offset -15 lines).

The reject file contains...

***************
*** 1103,1109 ****
    if (isset($offset) && !is_numeric($offset)) {
      $dtz = new DateTimeZone($offset);
      $dt = new DateTime("now", $dtz);
-     $offset_seconds = $dtz->getOffset($dt);	
    }
  
    switch ($db_type) {
--- 1112,1118 ----
    if (isset($offset) && !is_numeric($offset)) {
      $dtz = new DateTimeZone($offset);
      $dt = new DateTime("now", $dtz);
+     $offset_seconds = $dtz->getOffset($dt);
    }
  
    switch ($db_type) {

Please link to issue mentioned in #19.

dawehner’s picture

This is already commited, so there is no point for your to apply it again. Please use the dev version.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

braindrift’s picture

Please link to issue mentioned in #19.

Zachmo’s picture

yes yes please please...

kevinob11’s picture

This is probably a little late, but here is the issue.

http://drupal.org/node/1002744

OnkelTem’s picture

Not sure if this is related to the subject, but probably someone would find this usable:
http://drupal.org/node/1140896#comment-4956266

Zachmo’s picture

Not sure when this got fixed but I just want to say I'm really digging the improvements to this function. The raw vs. rendered data is awesome. Thank you for all your hard work.

oianinha’s picture

#30 works for me :) tks !

19 Posted by OnkelTem on September 7, 2011 at 10:17am
Try adding a field which value you need to the sort.
(https://drupal.org/node/1140896#comment-4956266)