Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I attempted to get an aggregated field containing a list of items into my view.
fulltext, max, min & sum seem to work fine.
Changing the datatype to list works for me.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 2828883--aggregation_data_types-9.patch | 734 bytes | JorgenSandstrom |
| |||
| #6 | 2828883-6--aggregation_data_types.patch | 643 bytes | drunken monkey |
| |||
Comments
Comment #2
JorgenSandstrom CreditAttribution: JorgenSandstrom for Miss Mary of Sweden commentedComment #3
drunken monkeyCan you please describe more clearly what you're trying to do and what goes wrong? Are you using Solr as the backend, or which are you using?
I don't really see what effect this patch could have on Views rendering, so some more research is needed on how this goes wrong with the other data type, and why this patch makes it work. I don't think this is the proper solution, in any case.
Also, another question would be whether just changing the field's indexed type to "Text" works, too, or whether you really need to change the property definition.
In the latter case, note that you can also easily override this (or maybe the resulting Views definitions, if that's the problem) with hooks just on your site, to fix this there.
PS: It seems you (like many others – it's really easy to misinterpret) are confused by the "Issue tags" field. As the guidelines state, they aren't meant for free text tags related to the issue, but only for specific categorization purposes, usually by module maintainers.
So, if you aren't sure your current usage is correct, please just leave the field empty.
Comment #4
drunken monkeyComment #5
JorgenSandstrom CreditAttribution: JorgenSandstrom for Miss Mary of Sweden commentedSo the problem for us is that aggregated fields of the type list are not available as fields in views.
We are using solr as backend and "Retrieve result data from Solr" checked.
This can be reproduced on a clean install of with search_api, search_api_solr and views.
1.) create an index with some fields + comments
2.) enable aggregated fields and add a list field for comments
3.) enable the newly created aggregated field and set as "full text"
4.) add some content
5.) create a view based on the index just created
The aggregated field is not available in views. After patch is applied and cache cleared the aggregated list field is available and working as expected.
I believe this may be due to "string" not being a valid data type for entities.
https://www.drupal.org/docs/7/api/entity-api/data-types
Sorry about using the issue tags field improperly.
Comment #6
drunken monkeyAh, yes, you're right! While "string" is a valid Search API data type, this particular method requires us to use valie Entity API data types, as per the method's documentation. However, instead of using "text", "token" would be the equivalent to our "string".
We actually already do that correctly in
SearchApiAlterNodeAccess::propertyInfo(), but it must have slipped through in the "Add aggregation" alteration.Anyways, please test the attached patch and tell me whether it also works for you!
Comment #8
drunken monkeyComment #9
JorgenSandstrom CreditAttribution: JorgenSandstrom for Miss Mary of Sweden commentedHi
I'm sorry for not replying to this earlier. We've been running the patch on production for quite some time now and is working as expected.
I've attached an updated patch that applies cleanly to -dev and latest 7.x-1.24
Comment #11
drunken monkeyNo worries, thanks for still reporting back and providing an updated patch!
Committed.