(Used 1.5 but don’t remember a thing :) ) Yes, what Steven says. If you try moving through each version then you will end up understanding a *lot* more about the application, but it sounds painful.
Your specific question seems to indicate that you would want your subclasses to actually share table information with the base class. proxy=True on the base class does the opposite, which would put data into individual tables which do *not* share any information with other subclasses or with the base class. But if that is OK then you should use it in the Meta definitions in the base class, which will then not have any table created for the base class. Your migration will be painful though since you won’t know how to break up the underlying data into the subclass tables. This gets uglier and uglier the more I think about it: how are these various models and underlying single table adding value? Are they just different views of the same data? But not implemented at the view level of the app? Or does the app have some magic which differentiates how those models are used at the app level? Lots of questions... If you can tolerate a bit of downtime for a changeover, then perhaps port the models and apps over to the newest LTS release, dump the current data, and then load it into the new app. Do this over and over as needed. When everything works, then take things offline, dump a final time, import it into your new deployment, and go. If you need to remap the old schema to something new, then perhaps use some temporary tables to hold data to be transformed. But working all the way from 1.5.x to 3.2.x or 4.x just seems like solving a bunch of problems along the way (all illustrating improvements in django, but that isn’t helping you) which could be ignored otherwise. hth - Tom > On Apr 5, 2022, at 6:13 AM, 'Steven Mapes' via Django users > <django-users@googlegroups.com> wrote: > > 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 >> <applewebdata://A5680ED0-6493-4F87-9559-5AE846AFB601>. >> 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 > <mailto: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 > > <https://groups.google.com/d/msgid/django-users/2fe87247-13ba-41d5-a38e-6915de6822b3n%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/3CBB92C9-62C6-4326-86DD-0056489B45B9%40gmail.com.
