On Mon, 2008-04-14 at 23:38 -0400, Michael wrote: > I think I convoluted my case by putting that related_name in there. > This doesn't work without the related_name option too. > > I was looking into it further and I realized that the problem with the > syncdb is the fact that m2m_db_table is the same on each inherited > field. Essentially this could be fixed by looking back into the model > that the manytomanyfield is supposed to be referring to. This involves > somehow getting access to the model of the manytomany field in the > curried function _get_m2m_db_table.
If that's all it is, then the fix should be pretty easy: for abstract base classes, the intermediate table name should be based on the name of the child model, not the abstract model. I can't drop everything right this minute to look at this, but I'm a little surprised that isn't happening already and it should be easy enough to fix when I get some time this evening. However that still leaves a problem in any case where m2m fields refer to the same model (or where somebody wants to specify the related name) in the abstract base class and that's probably going to be a case of hard cheese. Abstract base classes are an aid, not a crutch. Fortunately, we can detect that problem and raise a sensible error (I was thinking about that over lunch and it doesn't seem too hard). Regards, Malcolm -- I don't have a solution, but I admire your problem. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
