Ticket #123 (closed defect: fixed)

Opened 6 years ago

Last modified 6 years ago

Problems when (apparently) models file is split into submodules

Reported by: miracle2k Owned by: andrew
Priority: major Milestone: 0.5
Component: commands Version: 0.6-pre
Keywords: Cc:

Description

I've split my models.py file into submodules, one for each model, and South gives me the following error when trying to do an initial freeze:

AssertionError?: ForeignKey?(<module 'apps.database.models.feed' from '/Users/melsdoerfer/Documents/Dev/Projects/mine/podster/web/podster/apps/database/models/feed.pyc'>) is invalid. First parameter to ForeignKey? must be either a model, a model name, or the string 'self'

Stepping through the code, here's what seems to be happening:

1) eval_in_context() builds a fake_locals dict and starts out with both 'feed' (the module) and 'Feed' (the model).
2) The model gets removed.
3) The fake models are added, lower-cased, but the feed model is not.
4) ModelsLocals?() makes 'Feed' fallback to 'feed'.

The problem is in step 3: The fake Feed model is not being added. The reason might be that the order in which the frozen models are defined in the migration is incorrect (changing the order did fix the issue for me). Initially, I thought the fact that I am using submodules means South doesn't know what the right order is, but considering that the models-attribute of the migration is an unordered dict in the first place, I'm no longer sure if that can be considered the problem.

Change History

comment:1 Changed 6 years ago by miracle2k

I now can see that there is already a "failed fields" mechanism that retries those fields after they failed once. However, an AssertionError? as raised in my case is not being handled.

comment:2 Changed 6 years ago by andrew

  • Status changed from new to assigned
  • Version set to subversion
  • Milestone set to 0.5

Yes, it seems the lowercase name for the model ('feed') conflicts with that of the module. I think, if I catch the AssertionError?, it should try again at the end and fix; I'll have a go at that.

comment:3 Changed 6 years ago by miracle2k

FWIW, catching AsssertionError? seems to work for me.

comment:4 Changed 6 years ago by andrew

  • Status changed from assigned to closed
  • Resolution set to fixed

Yes, that's useful (it was taking ages to replicate this). Fixed in [218].

Note: See TracTickets for help on using tickets.