Closed (fixed)
Project:
Services
Version:
7.x-3.x-dev
Component:
Miscellaneous
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
7 Jan 2010 at 18:29 UTC
Updated:
4 Jun 2014 at 14:22 UTC
Jump to comment: Most recent
Comments
Comment #1
dawehnerI guess you use taxonomy: all terms? You have to look the data up in the field handler, got the the values.
Comment #2
mga commented@dereine thanks for the reply but I am not sure what you mean.
Comment #3
dawehnerCan you export the view, which you are trying to use? I thinks its easier to help you then :)
Comment #4
merlinofchaos commentedThe problem is services. Services assumes all data will be in $view->result, but this is not true if extra queries are needed. $view->result only contains the result of the primary query.
Comment #5
mga commentedI can export the view if needed. If $view->result does not have enough data, what must be done so it contains all the necessary data?
Comment #6
mga commentedHere's the exported view:
Comment #7
mga commentedHi
It seems the Views service used to be configured to return the whole node data but for some reason someone decided to change that in later releases (comment #3):
http://drupal.org/node/305155
Changing the lines of code mentioned in the patch now returns almost all the data from the node (except ImageCache data that you can easily build based on the original photo data).
HTH
Comment #8
gddComment #9
waldmanm commentedI'm not sure this should be closed.
Returning the whole node object for 'node' row style is a good workaround and definitely more useful than returning just the nid. But it has its own possible performance issues.
What would be ideal is to use 'fields' row style and get through the views.get service all the fields that you see in the view live preview. Specifically, I seem to not be able to get any field where I group multiple values (such as cck taxonomy, but even just a text field with multiple rows). The field doesn't appear at all in the returned data. Conversely, if I don't group multiple values of such a field, I get multiple rows in the view for each node, which is just much harder to parse.
I understand this data is not in $view->result, but to echo @mga in comment #5 - is there anyway to get this data returned from views.get?
Thanks.
[For future reference, should I have changed the status back to active? I do hope someone will be reading this, being that the issue is closed ...]
Comment #10
gddNo you did the right thing leaving a closed issue closed, however yes the maintainers are reading the messages.
I am currently pondering what to do about the views situation. We have a problem in that we have limited time to get this done but we want something that works for everyone as well. More to come.
Comment #11
mga commentedGood to know I am not alone in this situation. I assume part of the slugginess of my server is now due to the performance tax in the change I made but I guess it's better than nothing.
My server is in a grid hosting environment and the plain-text version is here:
http://www.mauriciogiraldo.com/vgline/
While the AMFPHP-connected visualization is here:
http://www.mauriciogiraldo.com/vgline/beta/
Notice quite the lag while loading events. I put a trivia thing to distract the user while she waits for the whole database to load. Not sure if 300 nodes is "a lot" though.
I did have statistics enabled (disabled now) and have cache turned on. Not sure what else I can do performance-wise.
Comment #12
tanius commentedI think I found a workaround (for JSON and XML) to get what #9 proposes: using the 'fields' row style and getting a data document with all the fields that you see in the view live preview. It works like this:
views_jsonorviews_xmldepending on the data format you want your view in.http://example.com/<endpoint path>/views/<view name>?display_id=<display name>&format_output=1So the trick was
format_output=1, which returns the view as rendered by Views itself. Normally that would be HTML output, but in this case it's JSON. And views_json can handle multiple value fields correctly (for services_views to do that, we have to wait for #2269845: Enhance (and fix) rendering of multiple valued field).The benefit of using a formatted JSON view via services_views rather than directly is still (at least) that you can access restrict the view and then use services_basic_auth for letting your client software access it via HTTP Basic authentication.
P.S.: Sorry for the version change, 6.x was not in the dropdown anymore. Or should we just reassign this issue to Services Views, as it got split out in the meantime?