Skip to content
This repository was archived by the owner on Apr 14, 2022. It is now read-only.

Relax 1:1 connection constraints (under an option) #135

Closed
Totktonada opened this issue Apr 26, 2018 · 1 comment
Closed

Relax 1:1 connection constraints (under an option) #135

Totktonada opened this issue Apr 26, 2018 · 1 comment
Labels
bug Something isn't working customer enhancement New feature or request prio1
Milestone
0.0.1

Comments

@Totktonada
Copy link
Member

  • Use name 1:1 for all 1:1 and 1:1* connections to simplify setup, but enforce constraints depending on user-provided options.
  • Allow to violate FULL MATCH constraint (see Write tests for a nullable index on shard #43) under an option: have both nulls and non-nulls in source fields set of an connection (need to check again three constraint types in Write tests for a nullable index on shard #43, maybe we can provide ability to choose an one of them).
  • Allow dandling connections under an option: source fields set of a connection that does not match anything in a destination collection.
  • Improve 'dangling connection' detection: remove false positive when filters passed for a connection or remove this constraint completely.
@Totktonada Totktonada added bug Something isn't working enhancement New feature or request customer labels Apr 26, 2018
@Totktonada Totktonada added this to the 0.0.1 milestone Apr 26, 2018
@Totktonada
Copy link
Member Author

Decided to introduce an option to allow dandling 1:1 connections, but don’t introcude an option to violate all-null-or-all-non-null FULL MATCH constraint (no need for now).

Totktonada added a commit that referenced this issue Jun 20, 2018
@Totktonada
Remove 1:1* connection, change 1:1 behaviour
100a2ec 
Changes in 1:1 connection behaviour:

* The case when all connection parts are null is allowed (gives null
  child object instead of an error).
* The case when no child object were matched is allowed.
  - FULL MATCH contraint does not verified entirely (further work is
    needed).
  - The following bug was fixed: usage of filtering arguments now cannot
    trigger 'expect one matching object' error if data are consistent.

Other changes:

* GraphQL auto configuration behaviour was changed in case when a
  connection parts count is the same with underlying index, the index is
  unique and some index parts are nullable and some are not. Now it
  generates 1:1 connection (and lean on runtime checks) instead of
  giving an error.

Part of #135.
Totktonada added a commit that referenced this issue Jun 20, 2018
@Totktonada
Implement runtime dangling 1:1 connection check
11d5e4e 
This check was implemented improperly: it can be triggered by an user
using filters that do not match anything. The check was removed in the
previous commit. Now it is implemented correctly.

The option 'disable_dangling_check' to disable this check was
introduced.

Fixes #135.
@Totktonada Totktonada mentioned this issue Jun 20, 2018
Merged
Totktonada added a commit that referenced this issue Jun 20, 2018
@Totktonada
Merge pull request #178 from tarantool/gh-135-relax-1-1-connection-co…
143c35e 
…nstraint

Remove 1:1* connections, relax constraints of 1:1 ones
Totktonada added a commit that referenced this issue Jun 20, 2018
@Totktonada
Return result in standard GraphQL format
844abfb 
Success case: {data = ...}
Error case: {errors = {message = ..., ...}}

compiled_query:execute(...) becomes exception-safe (performs pcall
internally), but graphql.new(...):compile() and
graphql.new(...).execute(...) still can throw an exception.

Enabled 5_2 test in common.test.lua, it fails before fix for #135 (
PR #178).

Increased timeout to 10 seconds in pcre.test.lua and
nested_args.test.lua (#137).

Prerequisite for #71.
Prerequisite for #134.
Fixes #137.
Totktonada added a commit that referenced this issue Jun 21, 2018
@Totktonada
Return result in standard GraphQL format
b541137 
Success case: {data = ...}
Error case: {errors = {message = ..., ...}}

compiled_query:execute(...) becomes exception-safe (performs pcall
internally), but graphql.new(...):compile() and
graphql.new(...).execute(...) still can throw an exception.

Enabled 5_2 test in common.test.lua, it fails before fix for #135 (
PR #178).

Increased timeout to 10 seconds in pcre.test.lua and
nested_args.test.lua (#137).

Prerequisite for #71.
Prerequisite for #134.
Fixes #137.
Totktonada added a commit that referenced this issue Jun 22, 2018
@Totktonada
Return result in standard GraphQL format
d4f4b76 
Success case: {data = ...}
Error case: {errors = {message = ..., ...}}

compiled_query:execute(...) becomes exception-safe (performs pcall
internally), but graphql.new(...):compile() and
graphql.new(...).execute(...) still can throw an exception.

Enabled 5_2 test in common.test.lua, it fails before fix for #135 (
PR #178).

Increased timeout to 10 seconds in pcre.test.lua and
nested_args.test.lua (#137).

Prerequisite for #71.
Prerequisite for #134.
Fixes #137.
Totktonada added a commit that referenced this issue Jun 22, 2018
@Totktonada
Return result in standard GraphQL format
61bee44 
Success case: {data = ...}
Error case: {errors = {message = ..., ...}}

compiled_query:execute(...) becomes exception-safe (performs pcall
internally), but graphql.new(...):compile() and
graphql.new(...).execute(...) still can throw an exception.

Enabled 5_2 test in common.test.lua, it fails before fix for #135 (
PR #178).

Prerequisite for #71.
Prerequisite for #134.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
bug Something isn't working customer enhancement New feature or request prio1
Projects
None yet
Milestone
0.0.1
Development

No branches or pull requests
1 participant
@Totktonada