mirror of
https://github.com/hasura/graphql-engine.git
synced 2024-12-18 04:51:35 +03:00
fe8eabff19
When adding object relationships, we set the nullability of the generated GraphQL field based on whether the database backend enforces that the referenced data always exists. For manual relationships (corresponding to `manual_configuration`), the database backend is unaware of any relationship between data, and hence such fields are always set to be nullable. For relationships generated from foreign key constraints (corresponding to `foreign_key_constraint_on`), we distinguish between two cases: 1. The "forward" object relationship from a referencing table (i.e. which has the foreign key constraint) to a referenced table. This should be set to be non-nullable when all referencing columns are non-nullable. But in fact, it used to set it to be non-nullable if *any* referencing column is non-nullable, which is only correct in Postgres when `MATCH FULL` is set (a flag we don't consider). This fixes that by changing a boolean conjunction to a disjunction. 2. The "reverse" object relationship from a referenced table to a referencing table which has the foreign key constraint. This should always be set to be nullable. But in fact, it used to always be set to non-nullable, as was reported in hasura/graphql-engine#7201. This fixes that. Moreover, we have moved the computation of the nullability from `Hasura.RQL.DDL.Relationship` to `Hasura.GraphQL.Schema.Select`: this nullability used to be passed through the `riIsNullable` field of `RelInfo`, but for array relationships this information is not actually used, and moreover the remaining fields of `RelInfo` are already enough to deduce the nullability. This also adds regression tests for both (1) and (2) above. https://github.com/hasura/graphql-engine-mono/pull/2159 GitOrigin-RevId: 617f12765614f49746d18d3368f41dfae2f3e6ca |
||
---|---|---|
.. | ||
pgdump | ||
queries | ||
remote_schemas/nodejs | ||
test_tests | ||
webhook/insecure | ||
.gitignore | ||
conftest.py | ||
context.py | ||
graphql_server.py | ||
jwk_server.py | ||
pytest.ini | ||
README.md | ||
remote_server.py | ||
requirements-top-level.txt | ||
requirements.txt | ||
super_classes.py | ||
test_actions.py | ||
test_allowlist_queries.py | ||
test_apis_disabled.py | ||
test_compat.py | ||
test_compression.py | ||
test_config_api.py | ||
test_cookie_webhook.py | ||
test_cors.py | ||
test_dev_endpoints.py | ||
test_endpoints.py | ||
test_events.py | ||
test_graphql_introspection.py | ||
test_graphql_mutations.py | ||
test_graphql_queries.py | ||
test_heterogeneous.py | ||
test_horizontal_scale.py | ||
test_inconsistent_meta.py | ||
test_jwk.py | ||
test_jwt_claims_map.py | ||
test_jwt.py | ||
test_logging.py | ||
test_metadata.py | ||
test_pg_dump.py | ||
test_query_cache.py | ||
test_remote_relationships.py | ||
test_remote_schema_permissions.py | ||
test_roles_inheritance.py | ||
test_scheduled_triggers.py | ||
test_schema_duplication.py | ||
test_schema_stitching.py | ||
test_subscriptions.py | ||
test_tests.py | ||
test_v1_queries.py | ||
test_v1alpha1_endpoint.py | ||
test_v2_queries.py | ||
test_validation.py | ||
test_version.py | ||
test_webhook_insecure.py | ||
test_webhook_request_context.py | ||
test_webhook.py | ||
test_websocket_init_cookie.py | ||
utils.py | ||
validate.py | ||
webhook.py | ||
webserver.py |
Running tests
The easiest way to run the test suite is to do:
$ scripts/dev.sh test
This should install python dependencies if required, and run in isolation. The output format is described in the pytest documentation. Errors and failures are indicated by F
s and E
s.
Tests Structure
-
Tests are grouped as test classes in test modules (names starting with
test_
) -
The configuration files (if needed) for the tests in a class are usually kept in one folder.
- The folder name is usually either the
dir
variable or thedir()
function
- The folder name is usually either the
-
Some tests (like in
test_graphql_queries.py
) requires a setup and teardown per class.- Here we are extending the
DefaultTestSelectQueries
class. - This class defines a fixture which will run the configurations in
setup.yaml
andteardown.yaml
once per class - Extending test class should define a function name
dir()
, which returns the configuration folder
- Here we are extending the
-
For mutation tests (like in
test_graphql_mutations.py
)- We need a
schema_setup
andschema_teardown
per class - And
values_setup
andvalues_teardown
per test - Doing schema setup and teardown per test is expensive.
- We are extending the
DefaultTestMutations
class for this. - This class defines a fixture which will run the configuration in
setup.yaml
andteardown.yaml
once per class. - Another fixture defined in this class runs the configuration in
values_setup.yaml
andvalues_teardown.yaml
once per class.
- We need a