feat: postgrest 13 add maxaffected in client libraries #619
Conversation
…tgrest-v13-integration' into avallete/psql-372-postgrest-add-maxaffected-in-client-libraries
| .maxAffected(2) | ||
| const { error } = result | ||
| expect(error).toBeDefined() | ||
| expect(error?.message).toBe('Query result exceeds max-affected preference constraint') |
There was a problem hiding this comment.
How about just matching the PostgREST error code? (PGRST124, ref)
This would allow us to change the error message without causing a test failure later. Right now the error message seems a bit specific to postgREST ("preference constraint" could be removed)
| .select() | ||
|
|
||
| expect(error).toBeDefined() | ||
| expect(error?.message).toBe('Query result exceeds max-affected preference constraint') |
There was a problem hiding this comment.
ditto here, only match error code if possible.
| @@ -0,0 +1,64 @@ | |||
| export class HeaderManager { | |||
There was a problem hiding this comment.
Can we use the Headers API instead? Should be available on both web and Node
There was a problem hiding this comment.
Great idea though and we should move to using that vs. plain objects/Records
| * | ||
| * @param value - The maximum number of rows that can be affected | ||
| */ | ||
| maxAffected( |
There was a problem hiding this comment.
Let's move this to PostgrestTransformBuilder since this doesn't do horizontal filtering, but rather an assertion a la .single()
What kind of change does this PR introduce?