Hi Corey, On Mon, 2006-10-02 at 02:06 -0700, Corey wrote: > I have put a custom manager in a file called managers.py. When I import > it in the model, and assign it to objects I get this strange error: > > unbound method contribute_to_class() must be called with AddressManager > instance as first argument (got ModelBase instance instead) > > I don't get the error when I add the manager class to the model file. > > If I import the manager in the shell, and instantiate it, it works > fine. > > Any thoughts?
Yeah, don't do that. :-) It's not an ideal situation and you could file a ticket so that we don't forget about it if you like. However, it's not going to be high priority at the moment, since it's easy enough to work around (and, on a more selfish level, slightly fiddly to fix, I suspect). It will be fixed eventually now that you've pointed it out (if you file a ticket), though, so don't be completely disheartened. More details than you possibly want to know... The reason it is happening is because of the global app/model cache we have in django/db/models/loading.py. This is needed in order for reverse relations to work without you needing to annotate both ends of the relation (e.g you only have to specify ForeignKey on one end, not both, but you can still access each model from the other one). This cache is very useful for this purpose, but the auto-discovery of the various relations it does leads to some fairly hairy setup under the covers and you seem to have hit a side-effect of this. By the way, Django never actually creates an instance of the model you ask for. Instead, it always creates a ModelBase instance, makes it look like your model and then renames it (Philosophy 101 question: so if something is indistinguishable from your model by all common measures, is it actually your model at that point?). The reference to ModelBase in that error message is not as bizarre as it sounds. If you're familiar enough with the code, it's actually very useful, because it points to exactly where the problem is going to be: in ModelBase.__new__. The reason it works when you are in the "shell" is because we have already set up that cache consistently by the time you have imported any class referring to a model. This isn't true in a program's normal execution (the consequences of *that* little featurette lead to some debugging nightmares, let me say, since the shell doesn't tell the truth in that respect). If you want to try and work on this on your own and come to some solution, you might want to read http://code.djangoproject.com/wiki/DevModelCreation as a starting point. If you do want to dive in an experiment, feel very free to ask questions; I have some clues about that area and am quite willing to help out. I don't have time to dive into that problem right at the moment, though, since there are just other higher priority things that need doing right now. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
