On Mon, Mar 11, 2013 at 5:58 PM, Shai Berger <[email protected]> wrote:
> Hi all, > > I would like to draw your attention to bug #8162[1]. It is old as sin, and > annoying as virtue. > You won't get any argument from me on this analysis. > The gist of it is: because, for all models, when the admin is present, > permissions are created automatically; because these permissions are named > "Can %s %s" % (action, model.verbose_name); that name gets put in a 50-long > charfield, and actions "change" and "delete" have length 6 -- so, > verbose-name > cannot have length >39. > > It gets even more annoying with automatic many-to-many fields, which have a > generated verbose name of "%s-%s relationship", limiting sum of lengths of > class names to around 25, forcing creation of an explicit "through" model > in > some cases. > > The bug was specified as a request to change the Permission model, and as > such > was (and is) triaged as "someday/maybe", supposedly waiting for schema > alteration in core. Other suggestions to resolve the issue have been > ignored; > in particular, a bug that pointed the problem without suggesting a (wrong, > IMO) solution was marked as duplicate[2]. > > Can we re-evaluate this, please? > Sure. Has schema alteration been added to core? No. Evaluation complete :-) To fix this, we need to alter the schema. Until we have a way to automate this process as part of a Django version upgrade, I don't see any practical way to fix this bug. The good news is that it's only the extreme cases that hit this bug -- class names of with names that are 25 characters or longer -- and if that's a description of your codebase, I'd say you've got other problems. This isn't Java. We don't need (or want) AbstractObserverInterfaceFactoryFactorySingletons in our code :-) (Seriously -- I know that there are occasionally good reasons for long class names -- I'm just saying they're an edge case, and an edge case that isn't *that* common in idiomatic Python) You say that "Other suggestions to resolve the issue have been ignored" - I'm unaware of any such suggestions. Can you point at or summarise them? If there's a viable option, I'd be in favour of applying that fix, but I genuinely can't say I see any option that is both backwards compatible, and doesn't require schema migrations. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
