Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Sqlalchemy adaptor error handling issue on "_create" #66

Closed
tunahan opened this issue Apr 24, 2021 · 3 comments
Closed

Sqlalchemy adaptor error handling issue on "_create" #66

tunahan opened this issue Apr 24, 2021 · 3 comments
Labels
wontfix This will not be worked on

Comments

@tunahan
Copy link

tunahan commented Apr 24, 2021

Hi, actually there is a need for a small development on _create as well(sqlalchemy.py). When inserting a row via post, I ended up with a different error message. I tried to insert a row into a table that have foreign key constraint on another table. The other table have no primary key value associated with row I tried to insert. So, I violated foreign key constraint.

except IntegrityError: db.rollback() raise HTTPException(422, "Key already exists")

As a result of code above, I get "key already exist". It could be something like that;
except IntegrityError as e: db.rollback() raise HTTPException(422, ", ".join(e.args))

@tunahan tunahan changed the title Sqlalchemy adaptor error handlign issue on "_create" Sqlalchemy adaptor error handling issue on "_create" Apr 24, 2021
@awtkns
Copy link
Owner

awtkns commented Apr 24, 2021

Hi @tunahan, this is actually working as intended. The idea behind not to show detailed error reports for database errors as I believe giving out details of your database setup to users is generally a bad idea.

However you do raise a fair point. it might be better to change it to simply "Integrity Error" as the message.

@tunahan
Copy link
Author

tunahan commented Apr 24, 2021

Hi @awtkns, Actually, you are right. The less detailed error stack the better and I agree with that. However, I believe, this level of information should be given. At least you might say "Ohh my friend, at least check the other table". That's it, there is no need for more detail, I believe.

Thanx, I appreciate your work!

@awtkns
Copy link
Owner

awtkns commented Apr 24, 2021

Awesome. Glad we agree. Generally it's a bad idea to give details about internal tables to users as it opens up potential vectors of attack.

I do think that a 500 something error code might make more sense though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants