Yes, it seems reasonable, because schema should deal with internal type and not with field flags such as field.many_to_many.
So, the summary is: For 1.8: https://github.com/django/django/pull/4014 Then https://github.com/django/django/pull/3998 (for 1.7 and 1.8 and current master) For 1.9: https://github.com/django/django/pull/4002 And remove isinstance(field, ManyToManyField) checks in the database schema. (maybe it will be included to 4002) суббота, 31 января 2015 г., 13:19:37 UTC+2 пользователь Markus Holtermann написал: > > Hey all, > > Since Django 1.8 (currently in alpha state), model fields gained cardinality > flags as part of the _meta refactoring. So, there is one_to_one, one_to_many, > many_to_one and many_to_many. These flags are currently only used inside > user-facing APIs such as forms and the admin. > > Furthermore model fields have a get_internal_type() method that returns > self.__class__.__name__ if they don't explicitly override that function (as > many of the built-in fields do). This method is heavily used inside the > backends. > > Besides those two ways to "try" to figure out what Django has to do in a > certain situation, the code uses e.g. isinstance(field.rel, ManyToManyRel) > and isinstance(field, ManyToManyField) to check for many-to-many > relationships. > > This is quite confusing. At least to me. In > https://github.com/django/django/commit/38c17871bb6dafd489367f6fe8bc56199223adb8 > I committed a patch that uses field.many_to_many in order to figure out if a > certain column needs to be copied from one table to another (it doesn't if > it's an m2m relation) when altering a table on SQLite. > > However changing that to use get_internal_name() and keep existing code > working is not trivial since neither ForeignKey nor ManyToManyField or > OneToOneField have those methods defined. Thus fields inheriting from either > of them need to explicitly define the method to return "ForeignKey", > "ManyToManyField" or "OneToOneField". (The backport of that patch to 1.7 > unfortunately breaks existing projects). > > I have a pull request open to fix the issue on 1.7 related to m2m fields: > https://github.com/django/django/pull/3998 . > > However, I don't really like that repetitive pattern of checking for > inheritance and get_internal_type(). I'm thinking about keeping the pattern > in 1.8 (and replacing the above checks with the one in the pull request) and > accept https://github.com/django/django/pull/4002 for 1.9. Thus all projects > and apps that rely on the class name of a related fields need to update their > code and explicitly return the class name. > > Thoughts and input highly welcome. > > /Markus > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/794e8343-9246-4b98-b5e5-1ab535f74373%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
