#25902: Add system check for project-wide database table name conflicts
--------------------------------------+------------------------------------
Reporter: amosonn | Owner: nobody
Type: New feature | Status: new
Component: Core (System checks) | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by amosonn):
I also noticed the other bug, but thought the behaviour django exhibits
there is more pleasant: it raises a clean, pythonic, internal error, and
does so when generating the migrations. In this case, it generates the
migrations silently, and then fails with a db error when applying them.
I'm unsure, but I think that a user who wants two models for the same
table, currently won't be able to do so without manually editing the
migrations, running one of the CreateModel-s (but not the other) with
SeparateDatabaseAndState - otherwise the second one will attempt creating
the table a second time, and the same db error will be raised.
So, what I think is that perhaps the system check is something that should
be run at makemigrations time, and issue a warning such as: "The
automatically generated migrations have two models ($names) with the same
database table, and will break when run. Consider giving those models an
explicit db_table. If you are modifying the migrations manually, you can
ignore this error." This covers both the case I described, in which the
user will go and give one of them (presumably the m2m) a name, and the
case you described, in which the user knows that he's doing something
strange, and will get a reminder that this has to be reflected in
migrations. It also covers a third case, in which the exact same app name
appears as two different submodules in the project, and which might
actually be more probable than both our previous cases.
I think such a check should not be too costy; perhaps I can add it, maybe
with some guidance as to where is the optimal place for it to reside.
I finally add that my original thought about this was that the problem was
with the default django table names. I still think that a table name of
shoppingmall_parking is better than shopping_mall_parking for the model
shopping_mall.Parking - just as in model names, the separation between
words using camelcasing is removed, so should be the separation between
words using underscores in app names. It is true that this doesn't cover
all cases, for instance some one with both x_y and xy as app names, but
that is even more uncommon.
--
Ticket URL: <https://code.djangoproject.com/ticket/25902#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.2ee5cf54da6bb27332026f9c924f9811%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
