one patch to fix a Django 1.8 issue for merging legacy database

[Ben L]

Issue: I have an existing database, so the guide in https://docs.djangoproject.com/en/1.8/howto/legacy-databases/ to inspect db and created models.py . 

That table does NOT have an 'id' column, and the created models.py doesn't have 'id' either, and the class is unmanaged (managed=False). But when I use Django to create page, the system failed, saying the 'id' is not found in the table. Somehow the query included 'id' in the select fields.

After a little bit of digging, I changed /usr/local/lib/python2.7/dist-packages/django/db/models/options.py:

Old:

line 284-287:

            else:

                auto = AutoField(verbose_name='ID', primary_key=True,

                            auto_created=True)

                model.add_to_class('id', auto)

New:

            else:

                if self.managed:

                    auto = AutoField(verbose_name='ID', primary_key=True,

                            auto_created=True)

                    model.add_to_class('id', auto)

Then my class will not get into this "AutoField" action to add 'id' in the query.

Looks like an apparent bug. This change works well for me. Please check and confirm whether this should be commit into you code base.

Thanks.

[Marc Tamlyn]

The automatic ID field would not be added if you have a primary key. I'm not sure if inspectdb does pick up primary keys, I believe it does though.

I feel this discussion may be more suited to django-users, our forum for helping debugging user issues.

Marc

--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/7dd7a80b-3b7c-4cb1-ab31-219c6c3ad3c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Shai Berger]

Hi Ben,

Thanks for the change you suggested.

On Tuesday 28 April 2015 09:48:26 Ben L wrote:

>[paraphrase] An automatic primary key shouldn't be added to unmanaged models,
>[paraphrase] the current behavior where it is added is a bug

Please have a look at the documentation[1] -- it states clearly that each
model requires a primary key field. Quite a lot of Django's behavior depends on
it -- in particular, you cannot save an instance of a model without a primary
key; of course, you cannot have another model point to it with an FK; etc.

So, the use case supported by your suggested fix -- an isolated table which the
Django app never updates -- seems to be supported by raw queries; the
potential for problems created by relaxing the requirement to have a PK, seems
to outweigh the benefits by far. Thus, I don't think we should accept your
suggestion.

Perhaps it may seem better to error out more gracefully when faced with
unmanaged models with no explicit PK. However, that would lead to funny
results when introspecting a schema which was, in fact, created by Django.

If I've missed anything, please explain,

Shai.

[1] https://docs.djangoproject.com/en/1.8/topics/db/models/#automatic-primary-key-fields