Suggest for patches should search on type instead of category.name

[Jaymassena]

We currently uses FTS on the patch name and category.name. Categories are dead and we are using type to suggest the intent of the patch. We should change our FTS search logic and indexing to use the type property instead of category.name. There is also the possibility of results that don't look right because patch category is still hanging around on older patches It might be a good idea to batch delete all the category fields from patches just to make sure there aren't interactions that we waste time on.

[georgesnelling]

I think the cateorgies have already been deleted.

https://api.aircandi.com/v1/find/patches/count?q[location][$exists]=true

count: 302

https://api.aircandi.com/v1/find/patches/count?q[category][$exists]=true

count: 0

I'm fine with deleting category.name from the index, but I'm not sure type is going to give you want you want. If I search for Pike Place Market do you really want all place type patches to be returned?

[Jaymassena]

OK, glad to see that the categories have been cleaned out. My understanding is that with text field weighting that "Pike Place Market" is still going to be at the top of my search list and I can use the event/group/project/place to tighten up the results as needed. If I just type in "place", I was always going to get a full list (which is limited to something like 10 I believe).

I think this is something that you have to play with to see how it feels.

[georgesnelling]

Thats right. I'm fine trying it. Between name, type, and description, what do you want the relative weights to be?

[Jaymassena]

name=10 type=5 description=3

[georgesnelling]

Implemented and tested with f48c1b983db663cf3398427dfc6642f6bbe85f97

Pushed to production with version 3.7.1

Try https://api.aircandi.com/v1/suggest/patches?input=place