Alpine is often slower than Debian (because musl is sometimes slower than glibc) and not how anyone actually deploys PostgreSQL in production.
Most notably, some floating-point computations result in slightly different values, and Debian ships with better support for different locales so sorting text (e.g. with `ORDER BY`) behaves differently.
Let's test against an environment that people are likely to actually use.
As a result, there are slight changes to the results of PostGIS computations in a couple of test cases.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10942
GitOrigin-RevId: 4caed19def23a372fc3930c409514b1c9b385026
This changes our test configuration to use the PostgreSQL 16 image from `postgis/postgis`.
In addition, it bumps PostGIS to v3.4 (from v3.3).
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10361
GitOrigin-RevId: 883c96d8453efb42b226f849891488382a99c80c
Now that Docker for macOS supports using Rosetta for x86/amd64 emulation, we no longer need to use the `azure-sql-edge` image. We can always use the official `mcr.microsoft.com/mssql/server` one.
This also means that we no longer need the separate healthcheck container, because the official image ships with `sqlcmd`.
When this is merged, you will need to ensure you have enabled Rosetta emulation in the Docker settings to test against SQL Server on macOS. This requires macOS 13 (Ventura).
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10139
GitOrigin-RevId: 2225bf5f4c6d3632da1f29b2229c9b04ead5e34c
The "Analyze" feature for SQL Server only partially worked. It would show the SQL generated, but not the execution plan. This is because SQL Server doesn't support generating a plan for prepared statements with parameters.
To work around this, we restructure the query as one without parameters. Instead, we replace each parameter with a variable. We declare the variables but don't set values. We then plan _that_, which works.
We run all this in a single query because local variables only last for a single transaction/batch.
This feature does not work for stored procedures.
[NDAT-582]: https://hasurahq.atlassian.net/browse/NDAT-582?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/10125
GitOrigin-RevId: a4b45b9b207456ff4fbd1b69b008e93f87346342
We test remote relationships across databases, and so running e.g. the "Postgres" tests also runs the "Postgres-SQLServer" tests, the "Postgres-Cockroach" tests, etc.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/9645
GitOrigin-RevId: bdc4e0f887d618f0c3b44868f552f545f0b228b0
Upgrade to GHC 9.4.5, and update any tests.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8954
Co-authored-by: Mohd Bilal <24944223+m-Bilal@users.noreply.github.com>
Co-authored-by: Samir Talwar <47582+SamirTalwar@users.noreply.github.com>
Co-authored-by: Philip Lykke Carlsen <358550+plcplc@users.noreply.github.com>
GitOrigin-RevId: 5261126777cb478567ea471c4bf5441bc345ea0d
The ports we use for testing often collide with other containers that other test suites leave lying around. This is annoying.
This fixes the problem by ensuring that PostgreSQL runs a on random port. FWe can query Docker to find out the allocated port.
I also changed the `make` target to run the agent too (though I kept the old behavior under a different target name).
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/9053
GitOrigin-RevId: 3ddea297905c0019c5ac42d896f5609f0d079e93
Upgrades Citus to v11.3.0 in tests.
This breaks an assumption made by the tests for the `get_source_tables` metadata API, in which data is expected to be ordered. We fix it by explicitly ordering rather than relying on the goodwill of the database.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/9039
GitOrigin-RevId: ee86db7e1c264d5009bb0203ac2f3fb2cda7b39f
I also pinned Citus to v11.3. This should hopefully stop us from being surprised with random test failures in the future. We will need to bump this every now and again.
I have updated the Makefile to standardize Docker commands, and made sure we start all the containers even when running tests for a single database, as we need to test cross-DB remote joins. This ensures `make test-citus` actually works and runs all tests.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/9035
Co-authored-by: Daniel Harvey <4729125+danieljharvey@users.noreply.github.com>
GitOrigin-RevId: 9c36ab65eb05206bfddd639c257d6c5c5cedd2bd
We bake the version number into the binary, which means that changing it causes a lot of files to rebuild (also thanks to Template Haskell). We can avoid this by simply using a dummy value which does not change.
When releasing, we still use the Git tag.
This should speed up the server build a lot, most of the time.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8916
GitOrigin-RevId: 7e5f9d4d582dba3eecab52fd37a216cadefba941
These tests ensure that upgrading HGE preserves the GraphQL schema.
They do this by running two different versions of HGE against the same metadata, and ensuring that the GraphQL schema doesn't change.
We might find that in the future, we make an additive change that makes these tests fail. Improving the tests to allow for this is left as an exercise to whoever triggers it. (Sorry.)
Currently, we do this with:
* an empty database (zero tracked relations)
* the Chinook dataset
* the "huge schema" dataset
The base version of HGE tested against can be overridden with an option. The version must be available on Docker Hub.
Further information is in the Haddock documentation.
[NDAT-627]: https://hasurahq.atlassian.net/browse/NDAT-627?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8982
GitOrigin-RevId: 97b4deda1e6fe1db33ce35db02e12c6acc6c29e3
