Migrations came in in 1.7 the docs for 1.8 show the following
*Prior to version 1.7, Django only supported adding new models to the database; it was not possible to alter or remove existing models via the syncdb command (the predecessor to migrate <https://docs.djangoproject.com/en/1.8/ref/django-admin/#django-admin-migrate>).**Third-party tools, most notably South <http://south.aeracode.org/>, provided support for these additional types of change, but it was considered important enough that support was brought into core Django.* I'd like to wish you good luck in making the move. I remember going from 1.8 to 1.11 was often a pain and 1.11 to 2 a little less. Personally depending on the size of the project I'd be tempted to dump the data against whichever data it is and start a whole new project from scratch then import the data in at the end and then use django dumps-data but I feel your pain On Monday, 4 April 2022 at 16:24:10 UTC+1 Antonis Christofides wrote: > This looks strange, although I'm not familiar with exactly this particular > use case. I'm assuming you are referring to multi-table inheritance. Are > you certain Django 1.5 wasn't creating these tables? Was it using > migrations or South maybe? (Obviously I don't remember when Django started > supporting migrations.) When you say it tries to query these tables, when > does it attempt to do so? Could you post an example of a subclasss, > preferably with its base class? > > > On 04/04/2022 09.09, John Abraham wrote: > > Hello. We're migrating someone else's app that was at Django 1.5.12 and > we're trying to bring it more up-to-date, step-by-step, starting with > Django 1.6.11. > > There's an odd thing. There were a bunch of subclasses of a Model class, > that didn't have any database fields. Django wasn't creating nor using > tables for them at 1.5.12. But, Django 1.6.11 keeps trying to query these > non-existent tables for these subclasses, expecting them to have a single > field which would just be the pointer to their superclass. > > It seems the proper way to tell Django not to use tables for a class is to > set: > > class Meta: > proxy = True > > But if we put this in, then when we run syncdb it strangly tries to query > the base classes before any tables are created at all in the database. > > Any old-timers run into anything like this? Did Django 1.5 not need the > proxy = True in the meta to avoid creating tables for subclasses of Models > that didn't add any fields? > > They are using InheritanceManager from django_model_utils. > > Thanks for any help! Banging our heads against the wall on this one for > quite a while now... > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/45eec62d-a27c-4b5e-b8ff-6fc2981efa17n%40googlegroups.com > > <https://groups.google.com/d/msgid/django-users/45eec62d-a27c-4b5e-b8ff-6fc2981efa17n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/2fe87247-13ba-41d5-a38e-6915de6822b3n%40googlegroups.com.
