-
-
Notifications
You must be signed in to change notification settings - Fork 33.1k
Fixed #18468 -- Added support for SQL comments in tables and columns. #12605
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
Fixed #18468 -- Added support for SQL comments in tables and columns. #12605
Conversation
close this pullRequest and i will reopen after modification |
@felixxm if i pull request to 2.2.2 , is it able to merge? |
No, we don't accept new features to the Django 2.2 or 3.0. This should be targeted to the Django 3.1. |
@felixxm (help_text is not relevant to db_comment) |
2020.04.05 support postgresql db_commentsupport oracle db_comment |
@felixxm |
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've left some comments that should relieve some of the review burden from the fellows, and hopefully point this in the right direction. Documentation and tests are missing, please address this! Please see the contribution documentation, and in particular the sections about test coverage for your patch. The feature freeze for Django 3.1 is approaching, so it's likely that you'll need to target this for 3.2.
It may be nice to include support for comments in the introspection of the different databases. Again, SQLite does not support this, so it's likely that another feature flag would come in handy. Although SQLServer is a third party backend, I didn't really see ways to extract this with the database views. I left some links for you to explore this:
- https://www.postgresql.org/docs/current/functions-info.html#FUNCTIONS-INFO-COMMENT-TABLE
- https://dev.mysql.com/doc/refman/8.0/en/tables-table.html
- https://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_2095.htm#REFRN20278
Another option would be to use those queries in tests that show that the database actually changes and stores the comments.
Things that should ultimately be in the final documentation are .. versionadded
annotations, documentation (with code examples) and tests.
It's not necessary to ping me whenever a part of the feedback has been addressed :)
sql_create_column_inline_fk = 'CONSTRAINT %(name)s REFERENCES %(to_table)s(%(to_column)s)%(deferrable)s' | ||
sql_delete_table = "DROP TABLE %(table)s CASCADE CONSTRAINTS" | ||
sql_create_index = "CREATE INDEX %(name)s ON %(table)s (%(columns)s)%(extra)s" | ||
sql_create_table_with_comment = "CREATE TABLE %(table)s (%(definition)s); " \ |
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.
Hanging indent is discouraged according to the coding style. See the vertical alignment
example.
sql.rename_table_references(old_db_table, new_db_table) | ||
|
||
def alter_db_table_comment(self, model, old_db_table_comment, new_db_table_comment): | ||
logger.info('option "db_table_comment" is supported only mysql ....') |
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.
The base class should not have database names in it. logger.info
is meant more for local debugging, rather than using it in the core of Django. And this appears to be for an early draft.
'definition': ', '.join(constraint for constraint in (*column_sqls, *constraints) if constraint), | ||
} | ||
|
||
if model._meta.db_table_comment and getattr(self, 'sql_create_table_with_comment', None): |
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 think the generic self.sql_create_table
could easily be adapted for this new scenario. Adding something like %(extra)s
. Then you also need to check only if the Model
defines that attribute. Please check how the index SQL construction is performed.
|
||
if field.db_column_comment: | ||
sql += " COMMENT '%(db_column_comment)s' " % { | ||
'db_column_comment': field.db_column_comment.replace('\'', '"').replace('\n', ' ') |
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.
Add trailing comma.
|
||
__all__ = [ | ||
'CreateModel', 'DeleteModel', 'AlterModelTable', 'AlterUniqueTogether', | ||
'CreateModel', 'DeleteModel', 'AlterModelTable', 'AlterModelTableComment', 'AlterUniqueTogether', |
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.
isort
should have handled this. Wrap imports at 79 chars.
|
||
sql_delete_procedure = 'DROP FUNCTION %(procedure)s(%(param_types)s)' | ||
|
||
sql_create_table_with_comment = "CREATE TABLE %(table)s (%(definition)s); " \ |
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.
Please see my comment about a generic template.
sql = self.sql_create_table_with_comment % { | ||
'table': self.quote_name(model._meta.db_table), | ||
'definition': ', '.join(constraint for constraint in (*column_sqls, *constraints) if constraint), | ||
"table_comment": model._meta.db_table_comment.replace('\'', '').replace('\n', ' ') |
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.
Please add trailing comma.
if old_field.db_column_comment != new_field.db_column_comment: | ||
fragment = self._alter_column_comment_sql(model, new_field, new_type, new_field.db_column_comment) | ||
if fragment: | ||
if self.connection.vendor not in ['postgresql', 'oracle']: |
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 not really sure what you're doing here. I'm not a fan of vendor names in the base schema class.
) | ||
|
||
def _alter_column_comment_sql(self, model, new_field, new_type, new_db_comment): | ||
raise NotImplementedError("column comment sql depend on Database Dialect, implement or return None") |
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.
You're defining the SQL in the backends, so I'm not sure subclasses need to do anything. I think it's worth investigating how you can make this completely generic, and have subclasses implement methods that you call from that method.
Closing due to inactivity. |
why don't you support SQL COMMENT ?
help_text is useful for Developer
BUT
DBA can not understand Django Models
They want to see db_comment with SQL not Python
This Issue causes a loss of communication costs between Developer to DBA
more detail description: https://code.djangoproject.com/ticket/18468
p.s. Only mysql has been implemented yetmysql(mariadb) oracle , postgresql has been implemented
Summary
CREATE TABLE with comment
ALTER TABLE with comment
ADD FIeld with comment
ALTER Field with comment