Views integration : handle 'multiple' fields

In fact the missing GROUP_CONCAT aggregator could probably be added in postgreSQL (there are other places in core where "custom" postgreSQL functions are added)

Which leaves us with the problem of MySQL 3 and 4.0.

Anyone knows if there is a way to branch code depending on the version of mysql used ?

Hell, in fact there is a way to branch code ... I found this in core (database.mysql.inc) :
if (version_compare(mysql_get_server_info(), '4.1.0', '>=')) {

Well, I guess I'll work on a new version of the patch, that uses the "optimal" method when possible, and the "suboptimal" for lower mysql versions...

What do you mean, talking to myself ?

OK, I'm a jerk, my "group_concat" solution does not work after all (does not work when there are several multiple fields - I guess I was being naïve...)

So we are left with my original "1 additional query per returned node" solution, and for now I have nothing better to propose. I guess that's the trade-off for the flexibility that multiple fields allow, and anyway it's better than the current behaviour (return one instance of a node for each value of the multiple(s) field(s))

Here's a slightly refactored version of the patch - basically, it's the same as in my original post.

Karen : Sorry, I can't do that, I'm currently away from my coding environment (vacation :-)
Won't be back before two weeks.

You shouldn't have too much trouble applying it manualy, though.

@bec : strange - they shouldn't.
I'm currently away from my coding environment so I can't test further ATM, but remember for sure that on my test views, nodes didn't show up multiple times...

Can anyone confirm the behaviour described by bec ?

bec, could you be more specific about the circumstances under which you see node duplication :
- decribe your content type
- "export" your view and paste it here

Plus please make sure that the node duplication is not triggered by something else in the view (taxonomy maybe ?...). Remove everything in your view that's not related to the multiple cck field, and see if that works...

Here's a re-rolled version against current 4.7

I can't reproduce the node duplication thing with my own test views / content types.
Bec or treylane, could you provide the additional info I mentioned earlier :
- describe your content type (a "content type" import / export feature would be useful here - well, later...)
- "export" your view and paste the result here

Please also make sure to empty your drupal cache and re-save your view.

It seems there's a number of people interested in this, so I'd really like to find the bug if there is one...

As a matter of fact, the more I think of it, the more I'm convinced the behaviour you describe is caused by outdated Views tables in cache.
As I said earlier, empty your cache (re-submit the "admin/modules" page, or use Devel module) and re-save your view - and please report here if the problem gets fixed or not :-)

OK, then this might be RTBC...

Sorry to ask again, but :
Are you sure it's the multiple CCK field that triggers node duplication ? (I don't really understand your "depending on how many options I've selected" part).
If you remove this field in your view, do you still get node duplication ?
Last : Did you try emptying the drupal cache and re-saving your view ?

With this patch, a multiple cck field does not add anything to the view-generated query (the 'multiple' values for the field are retrieved separately, in a subsequent query in the field handler function).
So there is no reason why it would trigger node duplication.

Er, your answer is confusing me...

Let's sum up.
This patch should _not_ require the "node:distinct" filter to avoid node duplicates.
Previous reports about duplicates were in fact caused by an outdated cache.
Before starting a bug chase, I need to know this not also the case for you, and your previous post doesn't allow me to make that out for sure.

Could you please try the following steps, in that order :
- (apply the last patch - that you obviously already did)
- empty drupal cache
- re-save the view (remove the "node:distinct" filter if any, but re-save the view anyway)
- see if the nodes still get duplicated

If yes, then we do have a problem, and in order to debug this I need you to :
- "export" your view and paste the result in this thread
- provide a 'textual' description of your cck content type (sorry, cck has no 'export' feature at the moment...)
- please confirm : you're using mysql 5.0.22/php 5.1.4, right ?

Thanks for your cooperation :-)
I'd really like to fix any possible bug, so that we can commit this - it seems some people are interested in the feature.
I don't reproduce the behaviour you're describing, so I'm depending on your precise answers here.

OK, I reworked this patch slightly.
The previous version was not satisfying in that it required the views tables to be rebuilt each time a field got its 'multiple values' status modified. Current patch keeps views tables constant, by deferring the differentiation between multiple and 'regular' fields in a field_query_handler function.

BUT when you change the 'multiple' status of a field, you still need to recompute the stored queries for the views that use this (cck-)field as a (views-)field.
This patch provides a _content_views_rebuild_views function to do that, and calls it when a field settings change (I'm not fond of this views-related part getting in content_admin.inc, but for now I could not find a cleaner way - suggestions welcome)

This patch also drops the 'list item' (<li>) theming, the bullets seemed to sort of get in the way. It uses the same display as 'regular node view' (multiple values in div's) by default, but lets the user theme this easily.

Notes :
- empty your cache and re-save your views after applying - when committing this, I'll add an update function to take care of that automatically.
- after some research (and sym not answering...), I think the "nodes get listed several times" issue in #18/#20 is not related to this patch, but rather to multiple fields being used as filters (or possibly sorts) - I'm working on this separately.
With this patch, Views with no filters / no sorts should NOT require the "Node: Distinct" filter.

Karen : both your last posts make valid points IMO
The "filter : all fields" is a good idea, I did not thought of that.
But yes, it has the drawback of being "one setting for all fields".
And, true, I can't think of a place where we could put a "group multiple values" option on the (view-)field.
(sort of related : see also my patch for a "is empty / is not empty" filter, and my proposal for "where to put it ?" : http://drupal.org/node/101050)

Maybe we could move this setting into a "Views settings" section on the (cck-)field settings page ? Not really ideal, but here at least we can stick all the options/params we like...

Er, this might actually be much more simple :

Currently the 'handler' column in the views-field table is empty for cck fields, because we define a single handler.
We could simply define two handlers : 'Group multiple values / Do not group multiple values', and the user picks one for each of the cck fields in his views...
Only thing is this would be displayed even for non-multiple fields, because we do not want to have to rebuild the views table when a field 'multiple' status is changed.

New patch, does as explained in #29.

The patch itself was not really hard to derive from my previous patch, but the feature adds "cryptics" to the code, and much complexity to testing it : what if the field is sortable ? what if the view has a sort / a filter on this field ? what if "Node : distinct" is used ?
Plus some peculiarities, making it hard for users to figure how their view will look, and which settings they should apply :
when "group" + make field sortable on table view, then "node: distinct" is required to avoid row duplication.
but if you choose "ungroup", "node: distinct" will filter out "redundant values" for the field
(e.g if a number field has the values 1 2 1, it will only show 1 2)

Well, this IS complex, and there's only so much we can do - multiple values are _not_ SQL friendly...
I'm quite sure we want the ability to group multiple values in a row.
Are we sure we want the ability to keep the current behavior ("ungroup") ?

OK, I can probably answer my last question :
Keeping multiple values separate can be useful when you want to provide a list of all the values in a given field.
So I guess we want both options
So the patch in #31 should be more or less what we want...

Oops - I forgot about module_exists / module_exist, and was not aware that views_cache.inc was 5.0 only...
I developped and tested in 5.0, and copied the relevant parts in 4.7 code to generate the patch. Not very serious I guess :-(.

_views_load_cache() is just here to include views_cache.inc, that contains _views_get_tables in Views 5.0
For 4.7, _views_load_cache() can go away.

I'll commit this (carefully) when I have some more time - thanks for the review and ideas !