Django 1.5 app had subclasses without tables without proxy and now 1.6 won't sync with proxy

[John Abraham]

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...

[Antonis Christofides]

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?

--
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.

[Steven Mapes]

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).
Third-party tools, most notably South, 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

[Thomas Lockhart]

(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

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/2fe87247-13ba-41d5-a38e-6915de6822b3n%40googlegroups.com.

[John Abraham]

Thanks for your responses. To clarify, I've used proxy=True on the subclasses (not the bass class) because they are polymorphic in their behaviour in some Python methods, but not in their persistent data.  I don't understand why South didn't create DB tables for them without the proxy=True flag being present.

The odd thing with the attempt to query the DB during syncdb, even before the DB was even made, seems to be related to an odd use of InheritanceManager from django-model-utils.  I seem to have gotten past that.  

We don't need to migrate the data in the DB.  The software populates the DB from Fixtures.  This makes debugging painfully hard, as the test case is basically "try to populate the database from all these fixtures over the next 10 minutes and see what errors show up".  Not a great testing strategy.  We might try another testing regime that involves populating the DB using the Django 1.5, then changing the Django version to 1.6, and running quicker, and simpler, tests.

Thanks again. We are making slow progress.  We'll consider some of the other ideas people have suggested too.

—

John