Question

Grouping Fields Within Views (3.44+)


Userlevel 3

Some users have wanted greater control over how fields are grouped in Looker’s field picker. Looker 3.44 adds the new group_label parameter to let you group fields together, even within the same view.


Existing Things You Could Already Do


Since 3.20 it’s been possible to adjust the first level of grouping (aka you can adjust the views) by using the view_label parameter.



type: time dimension groups have also automatically grouped together within each view for quite a while:



New Things You Can Do in 3.44


As of 3.44, you can control how the fields are grouped within each view by using the new group_label parameter. For example, you could create a group of shipping fields that would look like this:



You would achieve this with the following LookML:


dimension: shipping_city {
sql: ${TABLE}.shipping_city ;;
group_label: "Shipping Info"
}

dimension: shipping_state {
sql: ${TABLE}.shipping_state ;;
group_label: "Shipping Info"
}

dimension: shipping_street {
sql: ${TABLE}.shipping_street ;;
group_label: "Shipping Info"
}

group_label also interacts with dimension groups in pretty handy ways. For example, this LookML will add a special date calculation into the existing dimension group:


dimension_group: created {
type: time
timeframes: [date, week, month]
sql: ${TABLE}.created_date ;;
}

dimension: special_date_calculation {
sql: my_fancy_pants_sql ;;
group_label: "Created Date"
}

It would look like:




Please keep in mind that there must be at least two fields in a group label for it to appear. Also, you can’t group dimensions and measures together in the same group_label. Even if you give a dimension and measure exactly the same group_label there will still be one group under dimensions, and one group under measures.



36 replies

This is awesome. Thanks y’all.

Userlevel 2

Is there any way to do multi-level group label nesting?


I have some pretty large and complex datasets, and I’d like to be able to do something like



  • Master Group

    • Sums

      • Sum Field 1

      • Sum Field 2



    • Percentages

      • Percentage Field 1

      • Percentage Field 2





Userlevel 3

Hey @tuple!


This is not currently possible but I have passed the idea along to product/engineering for you!

Userlevel 2

Thanks, Nicole. Much appreciated. I’d be glad to demo in more detail what I am trying to do if it would be helpful.

Userlevel 3

@tuple In the example you gave, you only had 2 levels of organization. If that’s all you need, you could use view_label for the first 1st level of grouping and group_label for the 2nd level of grouping. But, if you want 2 levels of organization within the same view (for a total of 3 levels), then there isn’t really a way to do that currently as @nbeyer said. I suppose you could use label to name things with the same beginning so they would appear together when Looker did its alphabetic sort.

Userlevel 2

Hi Brett –


Yes, I need two (or even more!) levels of organization within the same view. I have already done the naming trick, but I don’t want to change field names too much because I want users to be able to understand something of the underlying data in Redshift. Also, I have hundreds of fields so even within a label group the sheer number of fields can overwhelm the user without the ability to have sub-groups.


Thanks,


Josh

Userlevel 1

+1 to @tuple’s request of multilevel grouping. A use case for us is to have a time dimension group within another dimension group. e.g. in your example above, ‘Shipping Info’ would be the first level, with shipping time/date/etc. as a time group within the ‘Shipping Info’ group.

Userlevel 3

  • 1 to this request

+1 to multilevel grouping

Is there a way to present a group as collapsed initially? Even if I collapse and save a Look, it seems to automatically expand, which to some degree defeats the purpose of grouping for ease of viewing/use.

Userlevel 3

@bgig I think that Looker will expand a list only if you’ve selected a field within it. Otherwise, the list should be closed by default. I don’t think it’s possible to modify either of these behaviors.

Brett - that’s not my experience.


I could find no way to get the list to start

collapsed. Before selecting anything, at the start of an new Explore, it

shows expanded in all cases I’ve tried… I am simply using group_labels on a set of dimensions.


I am on v. 3.54.16 if that matters.

Userlevel 3

That’s my experience as well.

Userlevel 3

@bgig and @ross I looked into this a bit more and found that the field groups should only start expanded if you only have a single view in your explore. For explores with multiple views (aka that have joins) they should start collapsed. Does this apply to your situation?

For each old LookML code block in this article and its comments, we just added the New LookML equivalent code.

Brett - My example is a single view - the view is of a single, non-derived table; and the explore only exposes that one table. Seems odd that only a join scenario would collapse grouping fields?? Thanks for the continuing responses!

Userlevel 3

@bgig I can see where you’re coming from, I can open a feature request for you to potentially change that behavior.

Yes please!

Userlevel 3

Overall, a very much needed feature that partially solves a problem of default redundant fields.


There are a couple of problems though:




  1. speed. With a large number of groupings, there is a significant delay in the time UI takes to load. I have now observed this across 3 models and tested against other factors, including # of view_labels and # of views/files. The groupings are the prime cause for delay.




  2. date groupings nest all dates together, making it unclear which date is which. This is a very common scenario:




in the events view, I might have a number of session-related timestamps, such as:


- dimension_group: session_start
type: time

- dimension_group: session_end
type: time


I would like to group these under a session group, but this will duplicate each of the timeframes in the UI (and a user won’t know which one belongs to which type of timestamp).

Grouping fields has been incredibly helpful. I wish I could specify a group_label in a join for an explore that would override any existing group_labels in the underlying view. This would allow for more flexibility and customization with group_labels & view_labels.

+1 to multi-level grouping

+1 to multi-level grouping

Userlevel 3

+1 to multi-level grouping

+1 to multilevel grouping

+1 to multilevel grouping

Reply