-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
MySQL and Postgres schema: retrieve columns' comments #2249
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still on the fence about accepting this. But one of the prerequisites would be that specs are added to test for expected behavior.
Thank you for your review! I've pushed the changes and updated the PR description with implementation notes, especially regarding how MySQL and Postgres adapters don't return the same thing when there is no comment. Do you think this is ok this way, or should I change it? |
Thanks for working on this. We should try to make behavior the same on both databases. Using Considering the patch isn't invasive, and some users will find it useful, I'm inclined to accept this. It does invite the slippery slope (people asking for table comments, support for setting comments, support for other databases, etc.), but I think those may still be better handled by external extensions. I looked briefly at Microsoft SQL Server support, and it's not a simple matter like it is on MySQL or PostgreSQL, so I don't think we should support similar behavior for it. |
You'll definitely get shoved down the slippery slope. It seems somewhat inconsistent to provide in-core support for just reading some kinds of comments on some database engines, while needing an extension to get more comprehensive support. A |
Change pushed To give you some context about the need, Sequel is a dependency of Langchainrb which is a dependency of a project I work on. The more info Langchainrb can retrieve from the DB, the better the underlying AI can perform – this is why reading is enough here. |
I agree that it seems somewhat inconsistent. However, if this handles the needs of 80% of users who would like some comment support, considering the limited invasiveness, I think it should be worth it. I would be open to expanding the same type of support by default on other databases, as long as it was of similar invasiveness, so the slippery slope there doesn't bother me too much. In terms of reading other types of comments, and writing comments, that would be a bigger issue, but maybe it isn't a problem to consider that. |
Looks like you need to update the MySQL adapter spec you added for the change. |
Woopsy, fixed |
Squash merged at b59c0aa |
Following this discussion:
Here is a PR to retrieve columns' comments (+ collation + privileges for MySQL).
As @jeremyevans shared, it may be more appropriate to build an extension, similar to @mpalmer's https://github.com/mpalmer/sequel-pg-comment. No hard feeling if the PR is rejected, I mostly pushed it because it fixes my use case, and it could help people who would come across the same issue.
Thank you for your help finding this solution!
Usage
Implementation notes
MySQL vs Postgres adapters:
For other fields, MySQL adapter returns empty string when there is nothing; while Postgres adapter returns nil. I followed this pattern–but it means the behavior isn't the same for the two of them. I don't have an opinion for this, feel free to comment.
Adding vs retrieving comment
This PR is only about retrieving comment, hence hardcoded SQL queries in the tests.
Tests