Group by field also groups by entity_id

What would be required here is to allow to select the raw data column in the field handler.
Currently there is a option for the database-value for clicksort but we could extend it to a general raw data column which is used on groupby, too.

This raw value has to be set to $this->real_field and will automatically be used by views_handler_field_group_by_numeric

That setting should probably be separate from the click sort column setting, someone might want to click sort on one, and group on another column...
We could group them in a fieldset though.

This issue has to wait on #1002744: Use entity_load for fieldapi field handlers

Also required: #1002764: Refactor the grouping code so that it can be extended.

Is the attached patch heading in the right direction (with some polish as it is hard-coded for a pager view of the default display)? It works with a single value "field" but has not been tested with a multi-value field.

As comment #4 alludes to refactoring the grouping code, this should probably go in a file specific to field API, e.g. views_handler_field_field.inc.

That looks very good.

Definitely something we can do without waiting for the refactoring (which is not that big of a priority in light of other issues).

Awesome!

Let's fix it first in 6.x-3.x

What i would really like to see is a possibility to alter the query out of the field handler.
The groupby_field handler could perhaps store other field handler and execute a certain function like query_groupby.

The attached patch for 7.x-3.x-dev attacks the problem at the source, adding a parameter to the 'additional fields' items in the field data. This parameter is passed to views_plugin_query_default->addField() and saved in the fields array where it can be utilized in views_plugin_query_default->compile_fields() to properly assemble the $non_aggregates list.

The patch only changes 6 lines of code. Unlike the previous patch, it should work regardless of the view or display plugin. It works with a single value "field" but has not been tested with a multi-value field.

If this makes sense, hopefully a similar approach can be utilized in 6.x-3.x branch.

My hunch is there are other "additional" fields that warrant the same treatment, e.g. those added to node, user, etc. and a @todo to that effect is included in the patch.

I think it is important to fix it, because it is a basic functionality.
e.g.
When I have a field with multiple values (like images) and the node can have 0 to 5 images, then it is the only way to group the images together and show only one row in the resultset for this node and not so much rows how images are there.

@solotandem

I general it would be cool if you could summarize what you talked with merlinofchaos in the irc :) Then this thing has a better documentation. THANKS!

The attached patch takes a different approach to enabling grouping with "field API" fields. It 1) conditionally adds form items to the group settings form and 2) takes advantage of the "use_group_by" parameter passed to query() methods (but not used by them, as the method signatures did not include it) to add fields to the query. As a simplification, the bundle column was moved to the regular "additional fields" code, leaving revision_id as the only odd man out. By default, only the specified "group column" is included in the query, but the user can specify certain other entity columns ('bundle', 'language', 'entity_type') to include and group on. As before, the additional columns do not result in items added to the display.

Last Friday in IRC, merlinofchaos and I agreed on the following points regarding the "field API" fields:
- grouping is a useful feature,
- when grouping applies, entities are not being retrieved, but rather collective (or grouped) information about entities is being retrieved
- including all the extra columns for an entity inhibits/prevents grouping, and
- therefore the views query should not include the extra entity columns (not requested by the user)

The documentation for field_view_field() indicates not all of the entity columns are necessary to rendering. And the code in the attached patch (as well as the previous one) also demonstrates/confirms this.

Made a quick peek.

+        $language = isset($row->{$this->aliases['language']}) ? $row->{$this->aliases['language']} : 'und';

'und' should be LANGUAGE_NONE, but after #1006176: Add support for field based translation lands, we can no longer assume that.

+      // @todo $object contains data for all the fields on this entity, not just the field_name field???

Yes, we need the full "entity-like" object in order for the whole thing to work, see #987478: Field language is not properly handled.

How is all this affected by bringing back entity_load?

The groupby works for me now (dev versions from 04 Jan 2011)

Okay here is a new version.
Adressed the issues from #12

Basically it moved quite some stuff to the handlers. This makes all much easier and clean.

After discussion in IRC with @dereine, the attached patch:
- moves the "if ($use_groupby) {}" in views_handler_field_field::add_additional_fields() to views_handler_field_field::query()
- eliminates views_handler_field_field::add_additional_fields()
- passes $fields to views_handler_field::add_additional_fields()

This eliminates a method and still keeps the field api code together.

Clean up code involving revision_id; eliminate switch block.

* Using a body and image field in both orders works fine.
* Formatters are working fine
* Groupby is working fine

What does not work but is currently unrelated to this issue is aggregate by the fieldapi field.

Fixed an issue with storing the group_type

Removed the todo's they are tackled.

Remove 2 @todos.

Commited to the 7.x branch. Thanks to everyone who worked on this issue.