Make constraint error details contain useful information for developers #6796
Conversation
aljazerzen
changed the title
edb/server/compiler/errormech.py
Outdated
| # details is for the "developer" that must explain what's going on | ||
| # under the hood. It should be picked up from the errmessage on the | ||
| # first ancestor constraint that's in std module. |
There was a problem hiding this comment.
This was my initial approach for the details
| # edgedb-python does not expose a nicer access to details field | ||
| details = e._attrs[2].decode("utf-8") |
There was a problem hiding this comment.
Am I doing something wrong here? Or does edgedb-python really don't expose error details field?
There was a problem hiding this comment.
Turns out that edgedb-python really does not expose details.
There was a problem hiding this comment.
I'll wait for a release of edgedb-python and clean this up before merging.
edb/server/compiler/errormech.py
Outdated
| @@ -599,6 +599,8 @@ def _interpret_constraint_errors( | |||
| # no need for else clause since it would have been handled by | |||
| # the static version | |||
|
|
|||
| print(error_type) | |||
There was a problem hiding this comment.
| print(error_type) |
edb/schema/constraints.py
Outdated
| ) -> List[Constraint]: | ||
| """ | ||
| Find the transitive closure of all constraints that apply. | ||
| Return parents of these constraints. | ||
| """ | ||
| # I'm not sure that this explanation is clear (or even entirely correct) |
There was a problem hiding this comment.
I don't think this explanation is quite right. I think it would be worth having clear documentation here, because there is a subtle issue at play.
The purpose of this function is to find which types an exclusive constraint originate from. If we have Baz <: Bar <: Foo, and Foo declares some exclusive constraint, then when we do an insert into Baz we need to check all Foos to make sure there is no conflict. (Which we do using triggers, and get_constraint_origin helps drive the generation of those.)
The subtleties here are:
- Because of multiple inheritance, we might have an exclusive constraint that originates from multiple unrelated ancestors
- Delegated exclusive constraints are declared on a parent, but their "origins" are their children. (So that
abstract type Namedor whatever can declare an exclusive name, but the names will be exclusive within each of the types that subtypes it.)
There was a problem hiding this comment.
I'll add these docs in a separate PR
This reverts commit 3ddc496.
…s on constraint violations
|
Let's merge it without waiting for edgedb-python, so we can backport it without needing to bump edgedb-python on those branches |
…new EdgeDB logic Constraints were standardized with: geldata/gel#6796 So now I parse out all the dynamic parts of the message for all constraint errors. I kept the subclass for now, but it could be replaced with the check ```diff - e instanceof ExclusivityViolationError + e instanceof ConstraintViolationError && e.constraint === 'std::exclusive' ```
…new EdgeDB logic Constraints were standardized with: geldata/gel#6796 So now I parse out all the dynamic parts of the message for all constraint errors. I kept the subclass for now, but it could be replaced with the check ```diff - e instanceof ExclusivityViolationError + e instanceof ConstraintViolationError && e.constraint === 'std::exclusive' ```
Closes #6768
Changes error details of constraint violations to:
... where
x_descriptionis thex.get_verbosename()