Django creates a table name by joining the app label with the model name. A project can have many apps. If two have the same label, how can both be used in the same database?
I’m currently using very long app names to minimize that risk (such as foo_bar_baz
instead of nesting modules like foo.bar.baz
– app label baz
). That might be overkill for an internal app (i.e. not meant for reuse), but I have also some modules that are generic and could be used in different projects (which I’m making freely available on the internet, so the possibility of name clashing is greater). If someone downloads my modules, finds a name collision with another third-party app, but doesn’t want to change either code (it would be a maintainance hell) what could he do about it?
I thought of “monkey patching” the apps to add a custom db_table
to each model, or Django, to change the way the default table name is derived, or maybe ensuring every app uses dependency injection to refer to other apps (so one could freely rename/symlink the app without breaking others that depend on it), but all options seem a lot of work and/or too easily broken. Is there an easier way? Should I drop all this altogether and just keep using fully-qualified names?
Let others monkeypatch your models’ table names. This is really better solved at the framework level. I wish schema/table naming was pluggable in Django (like Hibernate does, for instance).
2