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?
Comment | File | Size | Author |
---|---|---|---|
#15 | 1063418-post-execute.patch | 3.97 KB | merlinofchaos |
Comments
Comment #1
dawehnerThis 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.
Comment #2
merlinofchaos CreditAttribution: merlinofchaos commentedI 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.
Comment #3
Zachmo CreditAttribution: Zachmo commentedDisappointing 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.
Comment #4
dawehnerAs 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.
Comment #6
Zachmo CreditAttribution: Zachmo commentedMaybe 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?
Comment #7
giorgio79 CreditAttribution: giorgio79 commentedOuch, 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?
Comment #8
merlinofchaos CreditAttribution: merlinofchaos commentedWe've recently added code that copies field api values to the result.
Comment #9
giorgio79 CreditAttribution: giorgio79 commentedFantastic, much appreciated.
Comment #10
kevinob11 CreditAttribution: kevinob11 commentedHas this change been committed yet?
When I view $view->result the field api fields still show "node".
Thanks
Comment #11
Zachmo CreditAttribution: Zachmo commentedThis is AWESOME news! Please let us know when it is fully integrated and ready for production.
Thanks for all your hard work!
Comment #12
kevinob11 CreditAttribution: kevinob11 commentedPer #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.
Comment #13
merlinofchaos CreditAttribution: merlinofchaos commentedThe 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.
Comment #14
merlinofchaos CreditAttribution: merlinofchaos commentedWell. 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.
Comment #15
merlinofchaos CreditAttribution: merlinofchaos commentedTry this.
Comment #16
kevinob11 CreditAttribution: kevinob11 commentedI'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.
Comment #17
merlinofchaos CreditAttribution: merlinofchaos commentedIt 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.
Comment #18
kevinob11 CreditAttribution: kevinob11 commentedJust 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
Comment #19
kevinob11 CreditAttribution: kevinob11 commentedNevermind, I just saw that issue queue regarding forcing views to put fields into the query. I will work from there. Thanks.
Comment #20
merlinofchaos CreditAttribution: merlinofchaos commentedHey wait, let's not throw away my patch here.
Comment #21
dawehnerThis seems to work pretty fine here.
Comment #22
kevinob11 CreditAttribution: kevinob11 commentedWorked well for me.
Comment #23
merlinofchaos CreditAttribution: merlinofchaos commentedOkay, committed.
Comment #24
Zachmo CreditAttribution: Zachmo commentedHeyo...
My patch failed on Hunk 2.
The reject file contains...
Please link to issue mentioned in #19.
Comment #25
dawehnerThis is already commited, so there is no point for your to apply it again. Please use the dev version.
Comment #27
braindrift CreditAttribution: braindrift commentedPlease link to issue mentioned in #19.
Comment #28
Zachmo CreditAttribution: Zachmo commentedyes yes please please...
Comment #29
kevinob11 CreditAttribution: kevinob11 commentedThis is probably a little late, but here is the issue.
http://drupal.org/node/1002744
Comment #30
OnkelTem CreditAttribution: OnkelTem commentedNot sure if this is related to the subject, but probably someone would find this usable:
http://drupal.org/node/1140896#comment-4956266
Comment #31
Zachmo CreditAttribution: Zachmo commentedNot 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.
Comment #32
oianinha CreditAttribution: oianinha commented#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)