Specifying column names for ManyToMany fields

[Steven L Smith]

Hello,

I've been charged with creating a front-end in Django for a MSSQL
database. It
has to stay in MSSQL for various other reasons, so just using our
normal
Postgres stuff won't work.

It is all working, except for the internal names of ManyToMany Fields.
Our DBA
likes to follow the CamelCaseStyle, and Django likes the
underscore_style.

The two options I've found are:

1.) Define the field like this, using through:
websites = models.ManyToManyField('Website',
through='DepartmentsWebsites',
blank=True, null=True)

The problem there is that a lot of the ORM is disabled when you use
"through",
and the admin won't display the MultipleSelectWidgets for a table that
uses
"through".


2.) Define the field like this, using "db_table":
websites = models.ManyToManyField('Website',
db_table='Departments_Websites',
blank=True, null=True)

The problem there is that the Departments_Websites table contains
columns
called ID, DepartmentID, and WebsiteID, but Django is still looking
for id,
department_id, and website_id.

Any thoughts? Or would it be a LOT more difficult than just telling
the DBA
that we have to be slightly inconsistent in our naming schemes?


Thanks!

====================================
Steven L Smith, Web Developer
Department of Information Technology Services
Nazareth College of Rochester
585-389-2085 | ssmi...@naz.edu
http://www.naz.edu/pub/~ssmith46
====================================

[steven314]

I haven't dug around in Django enough to know if there is a Django
solution, but from the database side a view might do what you want? I
have not tried this myself.
http://msdn.microsoft.com/en-us/library/ms187956.aspx

So define a view that follows the Django naming convention, backed by
a table that follows your DBAs preference. Depends on your SQL Server
version, of course, as older versions may not allow you to update the
view.

> It has to stay in MSSQL for various other reasons, so just using our
> normal Postgres stuff won't work.
>

> Or would it be a LOT more difficult than just telling
> the DBA that we have to be slightly inconsistent in our naming schemes?

It sounds like you already have an inconsistency in the choice of
database so why not go the whole hog ;-)

Steven.

[Russell Keith-Magee]

Apologies for taking so long to respond.

This is quite an old issue; it was originally logged as #785. The
solution you propose in (2) is closest to the originally proposed
solution.

However, #785 was closed when #6095 (m2m intermediate tables) was
introduced; rather than add lots of new parameters to ManyToManyField,
the decision was made to use a manually created m2m through model for
the purposes of table customization.

In this case, the situation you describe in (1) is a bug -- a simple
through model *should* be able to use the MultipleSelect widget, but
can't.

I'm inclined to call this an extension of #9475 -- a proposal to
ensure that the add()/remove() shortcuts continue to work with m2m
fields if the through model doesn't add anything beyond the basic
foreign keys to other models. At present, if you manually define a
through model, you lose the add()/remove() shortcuts on the m2m
relation. However, this limitation is only strictly required if the
through model has addition fields with non-default/non-nullable
values. This is essentially the same condition that would be
preventing the use of the MultipleSelect widget in admin.

Yours,
Russ Magee %-)