Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

fix: clarify PGRST116 error message #3795

Merged
merged 1 commit into from
Nov 20, 2024

Conversation

steve-chavez
Copy link
Member

@steve-chavez steve-chavez commented Nov 19, 2024

Currently it's redundant.

{"message":"JSON object requested, multiple (or no) rows returned",
"details":"The result contains 0 rows"}

Now:

{"message":"Cannot coerce the result to a single JSON object",
"details":"The result contains 0 rows"}

Also correct docs which had a wrong error code.

@wolfgangwalther
Copy link
Member

fix: clarify PGRST116 error message

Is this really a fix? I don't think so, nothing is broken. I wouldn't backport it.

Imho it's just "changed". In conventional commits, this would still be a "feat", I think? Not sure. I guess I don't like strict conventional commits...

Currently it's redundant and not easy to read.

```
{"message":"JSON object requested, multiple (or no) rows returned",
"details":"The result contains 2 rows"}
```

Now:

```
{"message":"Cannot coerce the result to a single JSON object",
"details":"The result contains an array of 0 objects"}
``

Also correct docs which had a wrong error code.
@steve-chavez
Copy link
Member Author

steve-chavez commented Nov 19, 2024

Hm, I did a fix commit on da1150d, which was about changing messages too.

Is this really a fix? I don't think so, nothing is broken. I wouldn't backport it.

I do think it's a "fix" (fixes error message redundancy), but not so critical to backport it. Definitely not a feature though, I would want to keep those clearly differentiated in commits and CHANGELOG entries because they correlate to breaking changes sometimes.

@wolfgangwalther
Copy link
Member

I do think it's a "fix" (fixes error message redundancy), but not so critical to backport it. Definitely not a feature though, I would want to keep those clearly differentiated in commits and CHANGELOG entries because they correlate to breaking changes sometimes.

Yeah, not blocking from my side. I just started to think more about what kind of commit messages / prefixes we'd like to use - eventually, so that we could standardize on.

@steve-chavez steve-chavez merged commit 6db245a into PostgREST:main Nov 20, 2024
25 checks passed
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants