Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Problem/Motivation
As part of the Views integration, we have lists of allowed values that depend on the project the issue is linked to. We need to build the same system on Search API.
Level Of Effort
It is estimated to take 2 days of effort to complete this issue.
Comments
Comment #1
Senpai CreditAttribution: Senpai commentedTagging for 'Drupal.org D7, project, solr'.
Comment #2
drummtag
Comment #3
pwolanin CreditAttribution: pwolanin commentedI think this is a really bad idea. Why we you use SearchAPI here?
If for some reason you can't do this in SQL, we should use the existing apachesolr integration module that's already running on d.o. Otherwise you'll have to manage multiple indexing queues (and we already know the search API one tends to be fragile).
Comment #4
Damien Tournoud CreditAttribution: Damien Tournoud commented@pwolanin: We already have a separate index for issues, as already explained by Derek on #949372: Port issue views to Search API so we can have a performant backend.
I never experienced the Search API indexing queue being "fragile". Do you have any suggestions for improving this if it is the case?
Comment #5
drummNot actually a solr issue, our Search API backend for issues probably won't be solr.
Comment #6
pwolanin CreditAttribution: pwolanin commentedStill seems to me like using search_api just to denormalize the data is a little wonky?
Comment #7
dwwI don't understand #6. The proposal is to use search_api for everything: index management, display, etc. I don't want to maintain multiple sets of default issue views. I just want one set of views to deal with, and let Search API be the level of indirection I've always needed. Plus, I can't tell you how tired I am of bug reports and feature requests for the project_solr module. ;) Drupal.org should be using less custom code if we can help it.
But all of this is totally off-topic for this particular issue. If you want to keep opposing Search API for d.o, please do it at #949372: Port issue views to Search API so we can have a performant backend not here.
Thanks,
-Derek
Comment #8
drummThe Search API index is currently set up to store strings for version and component. The exposed filter is a basic text field and needs to be altered by Project Issue to be a select.
The index stores IDs for project, user-related fields, and tags. The exposed filter needs to be altered to be an autocomplete. SearchAPI autocomplete help a little here, but I felt like I was fighting it more than it was doing us favors. It was almost relying on indexing tricks and didn't really support multiple autocompletes well.
Comment #9
drunken monkeyFor non-fulltext fields, Search API Autocomplete is probably really the wrong option, especially with a database backend. Since there will be custom code in any case, you might be better off to completely implement autocompletion for those fields yourself. Since the data set is always the same, and shouldn't (I think) depend on the values entered in other fields, Search API Autocomplete is really a poor fit here.
The fact that the options depend on the current project makes this much harder again, too, of course. In that sense, Search API Autocomplete would really help, by automatically restricting the options – however, you then wouldn't be able to select components or versions for which no (matching) issue has yet been created, which might be unexpected.
Comment #10
drummComment #11
drummLooks like this is going to work much like Project Issue already works.
http://drupalcode.org/project/project_issue.git/commit/af0b3cf changes the handler for the project filter provided by SearchAPI.
http://drupalcode.org/project/drupalorg.git/commit/8c9e65d updates the settings to use it in Drupalorg for project/issues/user.
Comment #12
drummhttp://drupalcode.org/project/project_issue.git/commit/468760f is a straightforward conversion of the dereference list filter for used components.
Comment #13
drummAnd finally, http://drupalcode.org/project/project_issue.git/commit/7c35178 for dereferencing versions.