On Tue, Oct 23, 2012 at 5:11 PM, Russell Keith-Magee < russ...@keith-magee.com> wrote:
> > > On Tue, Oct 23, 2012 at 6:52 PM, Andrew Ingram <andrewof...@gmail.com>wrote: > >> Hi all, >> >> This one stung me today. Basically as part of an event (calendar) app, I >> have functionality for splitting a series of events into two at a given >> timestamp. The details aren't particularly relevant, but the key thing is >> that I had a method called "split" on one of the models. >> >> This was working fine until I tried to add a ManyToManyField to the same >> model, at which point it through a rather ugly error during initialisation >> of the apps. >> >> django/db/models/fields/related.py line 56, in add_lazy_relation >>> app_label, model_name = relation.split(".") >>> TypeError: unbound method split() must be called with RecurringEvent >>> instance as first argument (got str instance instead) >> >> >> Because I had no knowledge of the inner workings here, this error wasn't >> helpful until pdb told me that `relation` was an instance of my model. The >> issue is that in this point in the code, relation can either be a model or >> a string 'app_label.model_name', so it's using the presence of a split >> function to determine which it is, me having a split function on my model >> breaks this check. Having a non-callable 'split' causes a similar problem, >> just with a different exception. >> >> Long story short, adding a 'split' method to my model caused the >> inner-workings of Django to break, I think the documentation should provide >> a list of attribute names that can't be added to a Django model without >> breaking things, though this is the first time I've ever come across such a >> problem so it might be a one-off. >> >> Hi Andrew, > > Thanks for that gnarly bug report. I'm a little surprised that the 'split' > name causes a problem here; based on my knowledge of Django's internals, I > wouldn't have thought that the situation you describe shouldn't be a > problem. My gut reaction tells me that the actual problem is somewhere else > in your model definition, causing the wrong object instance to be passed > into the 'relation' variable; the 'split' method is a symptom, rather than > the actual problem. However, I may be wrong. > > If you can open a bug report with a complete working (or rather, broken) > example of the problem, we can dig into it more. If you're right that the > split method is the problem, we should certainly document it; if the > problem lies somewhere else, there's possibly some better validation that > we need to do. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > No this is a bug in Django, I see it. https://github.com/django/django/blob/master/django/db/models/fields/related.py#L51 Basically some genius (very likely me), decided we shouldn't type check for string or model, and just try to call split. It's an easy enough fix. Please file a bug and if there's no patch I'll do it tonight. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.