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.

Related issues

Comments

Senpai’s picture

Issue tags: +solr, +project, +drupal.org D7

Tagging for 'Drupal.org D7, project, solr'.

drumm’s picture

Issue tags: +16hr

tag

pwolanin’s picture

I 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).

Damien Tournoud’s picture

@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?

drumm’s picture

Issue tags: -solr

Not actually a solr issue, our Search API backend for issues probably won't be solr.

pwolanin’s picture

Still seems to me like using search_api just to denormalize the data is a little wonky?

dww’s picture

I 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

drumm’s picture

The 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.

drunken monkey’s picture

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.

For 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.

drumm’s picture

Assigned: Unassigned » drumm
drumm’s picture

Looks 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.

drumm’s picture

http://drupalcode.org/project/project_issue.git/commit/468760f is a straightforward conversion of the dereference list filter for used components.

drumm’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.