Posted by killes@www.drop.org on October 27, 2009 at 10:34pm
5 followers
Jump to:
| Project: | Content Construction Kit (CCK) |
| Version: | 6.x-2.x-dev |
| Component: | Views Integration |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
to reproduce
1) create a node based view
2) add node.type as a filter
3) add e.g node.title as a field
4) only title and nid are in SELECT
5) add a cck field as another field.
5) observe that suddenly node.type is also in the SELECT part.
5) is the bug, it was not requested to be added.
Comments
#1
This actually is unrelated to the filter part. I think adding any CCK field will cause the type to be added to the SELECT.
The reason this is a problem is that killes is trying to work with GROUP BY stuff and that breaks the GROUPing. I realize that some fields do need the type, but not all. I believe the type is only needed for multiple fields.
#2
The 'type' is added as an extra field in content_handler_field::init() and content_handler_field_multiple::init().
The reason is: once the field values are extracted from the db, rendering goes through content_format() which expects a '$node'. We don't need a full-fledged $node, but node type is specifically needed to retrieve the specific settings of the field for the node type (the field instance).
If the addition of 'type' really ruins queries, I guess it could possibly be retrieved in a separate pre_render() query, similar to what we already do for 'multiple field' values... I won't work on that patch, though :-/
#3
I'll see how bad the breakage of my queries actually will be and that will determine my interest in working on this. :p
It is possible that you simply always need to add node.type into the GROUP BY clause and hope that it doesn't influence your result.
If you do not do that, you can't even select minimum and maximum from a CCK field which would pretty much suck.
#4
Isn't the job of the one who adds the GROUP BY clause to do it properly? I mean, there may be more fields in the SELECT part, and GROUP BY requires the list of all fields not involved in aggregate functions. So the one who adds the GROUP BY clause needs to know which columns need to be in the list.
If this is not fixed in that way, then you'll have problems with any other column added by someone else. It is not only CCK who may need to add additional columns to the query. That's a Views feature.
#5
Markus: How so? What is Views supposed to do about it if field A adds stuff into the SELECT list?
#6
Isn't it possible to retrieve the list of fields that Views will use in the SELECT part (including additional fields) to derive the list of fields that needs to be passed to the GROUP BY list?
#7
#8
I too am working on group by functions, specifically trying to aggregate values based on a nodereference field.
Trying to group by the referenced nid is impossible as the nid, vid and node_type all get added to the query, and therefore to the group by, the only easy option I see so far is to hack views to ignore ANSI Sql like this post here:
http://drupal.org/node/385158
That being said, I have yet to get my hands dirty with a views handler n such, so Im not super clear where to start overriding things, but it sure would be nice to get cck values in views without going through content_format().
#9
group by is currently committed to 3.x-dev so you may want to play around with it a bit. Unfortunately that version of Views is not terribly stable at this time.
#10
A patch for testing has been posted in another issue, so I'm marking this one as duplicate. Please, see #695298: Allow CCK to work with GROUP BY support in Views