When I use the option that groups all values of a multi-value field into a single row in table view, obviously I can no longer sort by that column.

However, the only other alternative is to allow it to create duplicate rows for each node, one for each value for that multivalue field..... problem is, it creates a row for all possible values even if the field contains no data. So if a field is allowed to have 3 values, it will create 3 rows no matter what....

Is there a way to get around this and only create a row duplicate for each non-null value of that field? I would have thought that was an obvious and common requirement?

Comments

dawehner’s picture

dawehner
Primary language German
commented

Did you tryed to set a filter for this multiple field?

colinjones’s picture

colinjones commented

Do you mean set a filter to remove all rows that this field is empty? No, I didn't think of that - does that work?

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Closed (works as designed)

It may be an obvious and common but it is also hard. The only way to do this is to have two different fields. One for the 'primary' which can only be single and one for any secondaries which can be multiple.

colinjones’s picture

colinjones commented
Status: Closed (works as designed) » Active

dereine - unfortunately, no that does not work! For the purposes of Views, each value is treated as a separate node and so has its own row in table view, but for the purposes of Filters, a single value in a multivalue field is treated as if all these "nodes" have values, so it filters out nothing.

merlinofchaos - I understand your suggestion, however it isn't really a solution at all as you then cannot sort by the "secondary" values which is useless if all values are of equal value/significance. The very fact that Views treats multivalue fields as if there are multiple nodes would suggest that the design should allow for this possibility - ie filtering back on the number of "nodes"/rows displayed, this leads me to suggest this is a design flaw rather than "by design", wouldn't you agree?

At the very least, if the objective of mulitplying the number of rows for each node with a multivalue field is to ensure that all such values are displayed and readable, then surely the most logical approach would be to suppress additional rows that this field has no value for - as otherwise you are simply displaying multiple instances of identical rows. An option to suppress these rows, by default, would be most useful (IMHO), but even better, truely treat these rows as individual nodes that the Filters can act upon, thus allowing for all possibilities?

merlinofchaos’s picture

merlinofchaos commented

then surely the most logical approach would be to suppress additional rows that this field has no value for - as otherwise you are simply displaying multiple instances of identical rows. An option to suppress these rows, by default, would be most useful (IMHO), but even better,

Do you know SQL? Do you understand how this works?

colinjones’s picture

colinjones commented

I am reasonably familiar with SQL, but not the specific Drupal schema for multiple values. BTW, when I say "rows" I am referring to the Views rows, not SQL table rows, if that makes any difference. Are you saying that something about the schema prevents the Views code from distinguishing between multiple values for the purposes of filtering in the way I mentioned above? Is it impossible for the code to return anything other than all the values as separate rows for display, or combining them using the grouping feature?

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Closed (works as designed)

I'm not really sure what to tell you here, unfortunately.

First, a Views row is the same as a SQL row.

If you have a 1::many relationship, such as you get with a multi-value field like CCK or Taxonomy, then when you JOIN that table, you get 1 row per field in the multi-value field. That's simply how SQL works.

Views goes to a great deal of trouble to allow this 'group multiple values' concept, which retrieves the values from a secondary query so that you don't get multiple rows. That does meant that sorting and filtering are no longer possible, because these come from a different query.

You talk about suppressing rows, but you can't do that. You talk about 'most logical approaches' but you view it from the end goal, and yes, that end goal would be lovely. But apparently, you feel that, gosh, nobody here ever thought of that, because all it took was for you to remind us that this simple and obvious thing should happen just by flipping a switch or something.

Well, unfortunately, you're wrong. It may be obvious, but it definitely is not simple.

colinjones’s picture

colinjones commented

merlinofchaos - there is no need to get nasty with me!

I never said nor implied that this was "simple" in terms of implementation. Nor did I imply that nobody here had thought of it. I was expressly asking questions so that I could understand where the limitation lay. And now you have explained that. My comments about "obvious and common" relate, as you pointed out, to the end goal not the implementation. I did not say the implementation would be simple, in fact I was asking for more information on the implementation to understand why it is like this - which you have now provided, thank you. I had/have no idea whether "[anybody] here ever thought of that", as I have only just come across the need for this situation, which is why I posted the question, to see if I had stupidly missed something completely or if anybody else had, indeed, had this need before.

Clearly I am not suggesting this for Views generally, as this option even to me seems a hack! But would it be technically possible for the rows returned to be placed in a temporary SQL table, and then a further SQL query issued against that table to filter out the multiple rows that have null for the multivalue field, prior to returning the rows to Drupal? Thus achieving the end goal, albeit in a very ugly way! Please don't fret if I have fundamentally misunderstood how the code works and this suggestion doesn't even make sense, I am still just trying to understand how this works - just say "doesn't make sense!"

Thanks for your help.