Specify the PG TS config 'english' on search

[bickelj]

While the postgres (PG) text search (TS) config 'english' is specified when building the text search column and index in the migration script 0010-alter-proposal_field_values-value_search.sql, when the postgres default_text_search_config is set to pg_catalog.simple rather than to pg_catalog.english, the test named returns a subset of proposals present in the database when search is provided in file proposals.int.test.ts will fail. For consistency in search results across instances, this commit sets the query with search to use the same english. Without this commit, tests will fail with different PG settings for default text search config and inconsistent search results will appear between instances.

Issue #336 Test failure on different pg text search settings

[codecov]

Codecov Report

Patch and project coverage have no change.

Comparison is base (308045f) 96.12% compared to head (faa71cb) 96.12%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #337   +/-   ##
=======================================
  Coverage   96.12%   96.12%           
=======================================
  Files          65       65           
  Lines         929      929           
  Branches      159      159           
=======================================
  Hits          893      893           
  Misses         35       35           
  Partials        1        1           

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[slifty]

great catch! (and hooray for tests!)

Out of curiosity... would it be possible to easily write an integration test that ensures this works when pg_catalog.simple is the configured setting? It would be worth including a regression test if so. If not, that's fine too.

[bickelj]

It was pretty easy to add a single statement to the existing test, setting the default config to 'arabic', which then causes the test to fail if 'english' is not specified in the select query. Does this look OK?

[bickelj]

Another thought I had was to use the exact bitnami image in our test that we use in prod. We don't have a non-manual way to synchronize that, however, and there is utility in testing with a recent postgres image. If I had to choose one or the other I'd test using the exact image we use in prod, but perhaps we should do both. What do you think, @slifty @jasonaowen ?

[jasonaowen]

Good digging, @bickelj! Thanks for fixing this.

[jasonaowen]

Another thought I had was to use the exact bitnami image in our test that we use in prod. We don't have a non-manual way to synchronize that, however, and there is utility in testing with a recent postgres image. If I had to choose one or the other I'd test using the exact image we use in prod, but perhaps we should do both. What do you think, @slifty @jasonaowen ?

Well, I have a few thoughts, in no particular order:

• we should have alignment between dev and prod, but maybe we should move in the other direction - can we stop using the bitnami image altogether? It's already varied from our expectations in a way that impacted functionality; will it do so again?
• we could run the tests against multiple versions with a matrix strategy
• rather than running a docker image, or running our own PostgreSQL at all, maybe we should be using Heroku or Digital Ocean; their tooling is better than anything we can build with the budget we have, and our engineering time is better spent on the application itself rather than on hosting

[bickelj]

I rebased on main and implemented the suggestion of splitting out the regression test from the original test.

Jason said:

• we should have alignment between dev and prod, but maybe we should move in the other direction - can we stop using the bitnami image altogether? It's already varied from our expectations in a way that impacted functionality; will it do so again?

• we could run the tests against multiple versions with a matrix strategy

• rather than running a docker image, or running our own PostgreSQL at all, maybe we should be using Heroku or Digital Ocean; their tooling is better than anything we can build with the budget we have, and our engineering time is better spent on the application itself rather than on hosting

I like the matrix strategy. Multiple versions would be good, e.g. "what we use in prod today" as well as "a latest version", and/or a "stock pg image" and a "bitnami pg image".

I looked for the download button for Heroku and couldn't figure out how to download a Heroku 😃

Digital Ocean's default configuration also sets simple:

defaultdb=> select name, setting from pg_settings where name like '%default_text%';
            name            |      setting      
----------------------------+-------------------
 default_text_search_config | pg_catalog.simple
(1 row)

Therefore we likely would have run into the same issue with Digital Ocean as the bitnami image. I don't know Heroku's default setting.

Regardless, I think we agree that we should align the tests one way or another. Because we already use containers in test and prod and because GitHub already uses containers during workflows I still think the best path is to use that image during the workflow.

[jasonaowen]

Thanks for splitting that test out!