Ahh, got it now. Thanks!

On Sunday, November 4, 2012 1:10:48 PM UTC-8, Andrew Ingram wrote:
>
> Hi Mike,
>
> It looks like I missed part of the problem, namely that abstract models 
> are involved. These model definitions should trigger the error:
>
> from django.db import models
>
>
> class Bar(models.Model):
> name = models.CharField(max_length=250)
>
>
> class AbstractFoo(models.Model):
> name = models.CharField(max_length=250)
> bars = models.ManyToManyField(Bar)
>
> def split(self):
> pass
>
> class Meta:
> abstract = True
>
>
> class Foo(AbstractFoo):
> pass
>
>
> It doesn't make a difference if the ManyToManyField is on the abstract 
> model or the concrete one.
>
> Regards,
> Andrew
>
>
> On 4 Nov 2012, at 20:42, Mike Johnson <mrjoh...@gmail.com <javascript:>> 
> wrote:
>
> Hi Andrew,
>
> I'm trying to come up with a test case for this and am struggling to 
> reproduce the problem in test.
>
> Can you post some code to help us reproduce it?
>
> Thanks,
> Mike
>
>
> On Tuesday, October 23, 2012 3:52:10 AM UTC-7, Andrew Ingram 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.
>>
>> Regards,
>> Andrew Ingram
>>
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/django-developers/-/95Ok89lqNjkJ.
> To post to this group, send email to django-d...@googlegroups.com<javascript:>
> .
> To unsubscribe from this group, send email to 
> django-develop...@googlegroups.com <javascript:>.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/Td4YsbPi4MoJ.
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.

Reply via email to