4 ms·

Very cool! I remember when kicking the tires on postgrest/postgraphile that I found validation and error handling to be one of the less intuitive areas. Not th

Very cool! I remember when kicking the tires on postgrest/postgraphile that I found validation and error handling to be one of the less intuitive areas. Not the actual field-level constraints, but how to adapt it to fit a fast-fail vs slow-fail model. When I had attempted before, the only ergonomic option was fast-fail (the first check constraint violated would bubble the error upward) rather than slow-fail (collect all invalid fields and return the collection of errors, which IME is more common on average web forms or api requests). Looking at the single code file and tests, I see only singular field errors. Has a more ergonomic approach to validation-error collection been developed other than writing a large function to iterate the new record fieldwise against the schema?

oliverrice 4y ago
> fast-fail (the first check constraint violated would bubble the error upward) rather than slow-fail (collect all invalid fields and return the collection of errors, which IME is more common on average web forms or api requests) ... > Has a more ergonomic approach to validation-error collection been developed other than writing a large function to iterate the new record fieldwise against the schema? Thats an interesting problem that makes sense in the context of form validation. re: have the ergonomics improved -> no but you could hack that behavior together like this: ``` create or replace function handle_errors(errors text[]) returns bool language plpgsql as $$ begin if errors = array[]::text[] then return true; end if; raise exception using errcode='22000', message=(select string_agg(x, ', ') from unnest(errors) v(x)); end; $$; create table account( id int primary key, email text, first_name text check ( handle_errors( array[]::text[] || case when email is null then 'email must not be empty' else null end || case when first_name is null then 'first_name must not be empty' else null end ) ) ); insert into account(id, email, first_name) values (1, null, null); -- ERROR: email must not be empty, first_name must not be empty ``` not that I'd recommend it :)
- Tostino 4y ago
  Heh I really wish they supported this natively in the DB. This would be super useful for crud stuff if you could just set a GUC and get the fail slow mode, and get a list of errors returned to the client.
- memco 4y ago
  Even in the fast fail case it would help if it told you which constraint failed. In the example from the readme it says the row failed validation, but not why. Would be nice if it said something like “items of `tags` must be type string, but integer was given”. Or even just that it was an invalid item type found in tags.

oliverrice 4y ago

> fast-fail (the first check constraint violated would bubble the error upward) rather than slow-fail (collect all invalid fields and return the collection of errors, which IME is more common on average web forms or api requests) ... > Has a more ergonomic approach to validation-error collection been developed other than writing a large function to iterate the new record fieldwise against the schema? Thats an interesting problem that makes sense in the context of form validation. re: have the ergonomics improved -> no but you could hack that behavior together like this: ``` create or replace function handle_errors(errors text[]) returns bool language plpgsql as $$ begin if errors = array[]::text[] then return true; end if; raise exception using errcode='22000', message=(select string_agg(x, ', ') from unnest(errors) v(x)); end; $$; create table account( id int primary key, email text, first_name text check ( handle_errors( array[]::text[] || case when email is null then 'email must not be empty' else null end || case when first_name is null then 'first_name must not be empty' else null end ) ) ); insert into account(id, email, first_name) values (1, null, null); -- ERROR: email must not be empty, first_name must not be empty ``` not that I'd recommend it :)

Tostino 4y ago
Heh I really wish they supported this natively in the DB. This would be super useful for crud stuff if you could just set a GUC and get the fail slow mode, and get a list of errors returned to the client.
memco 4y ago
Even in the fast fail case it would help if it told you which constraint failed. In the example from the readme it says the row failed validation, but not why. Would be nice if it said something like “items of `tags` must be type string, but integer was given”. Or even just that it was an invalid item type found in tags.