Hi Russell, I'm reordering the text I'm replying to below, to make things clearer.
On Monday 11 March 2013 12:14:22 Russell Keith-Magee wrote: > On Mon, Mar 11, 2013 at 5:58 PM, Shai Berger <[email protected]> wrote: > > > > 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. > Good :) > 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. Sorry, but the good news is wrong; it is not the class name that is inserted into the permission name, but the verbose name. The limitation is 39, not 25, and yet it is met easily in systems where entities are complex enough. If this weren't the case, the bug wouldn't be annoying. The limitation of ~25 is not for single class names -- it is for combinations of two class names, in the specific case of automatic many-to-many fields. <sophistry>I hope you'd agree that 12 is too little for class names even in Python</sophistry>. This is not Java, but not APL either. > 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. > The "name" field of permissions is filled this way because it is, primarily, a display name. The field that is intended for lookup is codename; a unique constraint is only applied to codename. My suggestion for a fix, therefore, is to change the generation of the field value, cutting the generated value down to 50. With most database backends, there can be no backwards-compatibility problem -- the "current behavior" value couldn't have been saved anywaty. With SQLite and MySql-in-non-strict- more, the behavior is arguably a bug, but I'd rather special-case them somehow and solve the problem for the rest of us. > > > > Can we re-evaluate this, please? > > Sure. > > Has schema alteration been added to core? No. > > Evaluation complete :-) > As I said, I think schema change is the wrong solution here anyway. That is what I want re-evaluated. Thanks, Shai -- 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.
