Add duty station search improvements: 167501188

[lynzt]

Description

Make searching for a duty station more flexible... allow "fuzzy" matching.

Use trigram matching when letting a SM or an Office user search for duty stations. Calculate the similarity between the "search query" and the duty stations and return the top 7 results.

Reviewer Notes

Alternate spellings/abbrs we want to catch are in the pivotal story linked as a spreadsheet.

Setup

Add any steps or code to run in this section to help others prepare to run your code:

make server_test
make server_run
make client_run

Log into SM or Office app and do a duty station search using "alternate" duty station names... or try fuzzy searching for things:

• ft bragg => fort bragg
• joint base => recs for JB *
• etc

Code Review Verification Steps

• The requirements listed in
  Querying the Database Safely
  have been satisfied.
• Any new migrations/schema changes:
  • Follow our guidelines for zero-downtime deploys (see Zero-Downtime Deploys)
• Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
• User facing changes have been reviewed by design.
• Request review from a member of a different team.
• Have the Pivotal acceptance criteria been met for this change?

References

• Pivotal story for this change
• this article explains more about the approach used.

Screenshots

[codecov]

Codecov Report

Merging #2760 into master will increase coverage by 0.1%.
The diff coverage is 100%.

@@           Coverage Diff            @@
##           master   #2760     +/-   ##
========================================
+ Coverage    57.6%   57.6%   +0.1%     
========================================
  Files         278     276      -2     
  Lines       12567   12550     -17     
========================================
- Hits         7233    7226      -7     
+ Misses       4586    4578      -8     
+ Partials      748     746      -2

Impacted Files	Coverage Δ
pkg/handlers/internalapi/transportation_offices.go	100% <100%> (ø)	⬆️
pkg/handlers/internalapi/duty_stations.go	87% <100%> (-0.5%)	⬇️
pkg/models/duty_station.go	50.7% <100%> (+15.7%)	⬆️
pkg/handlers/adminapi/api.go	0% <0%> (ø)	⬆️
pkg/services/office_user/office_user_fetcher.go
pkg/services/office_user/office_user_updater.go
...g/services/office_user/office_user_list_fetcher.go
pkg/handlers/adminapi/admin_users.go
pkg/services/office_user/office_user_creator.go
pkg/services/admin_user/admin_user_list_fetcher.go
... and 5 more

[lynzt]

There's another pivotal story that deals with the fact we're doing an Eager("address") when looking up duty stations for the user to choose from...

[chrisgilmerproj]

💯

[chrisgilmerproj]

Awesome work! Can we test this on experimental with the load testing framework? I can show you how.

[Ryan-Koch]

We might be able to get away with using the % operator with these similarity calls, if we set the pg_trgm.similarity_threshold to the 0.03 value we're using (default is 0.3, so definitely would need to override in that case). Since the operator returns a true/false based on the threshold as opposed to the value, I suspect it might run a bit faster (I wouldn't hold the PR up over this, just something to think about).

[lynzt]

I didn't use % in case we want to tweek the similarity threashold and figured it clearer what was happening if things were in the query... and setting the threashold didn't add much/any speed gains since we're not dealing w/ a ton of rows.

However, if/when we add additional duty stations - we should def. keep this in mind for query optimization.

[Ryan-Koch]

This looks really great! I left a minor comment about the query, but otherwise this seems to do what it's supposed to. I think after the load testing that was mentioned in another comment it's good to go. 🚀

[lynzt]

@chrisgilmerproj results from load testing.

[chrisgilmerproj]

🚀 - Awesome work. Thanks for doing the load testing check on this endpoint because its caused us so much trouble in the past.

Also, don't forget to undo the changes to experimental :)

[lynzt]

@chrisgilmerproj do you mean pushing to experimental again to reset the auth variable?
I've already had @rdhariwal add the rate-limiting back in the other repo...

[chrisgilmerproj]

@chrisgilmerproj do you mean pushing to experimental again to reset the auth variable?
I've already had @rdhariwal add the rate-limiting back in the other repo...

Yep! You'll want to turn off that variable. And then remove the stuff from this PR.