The length of Permission.name field in django.contrib.auth module is not enough.
The name field in Permission model in django.contrib.auth module causes problems when one of the fields' verbose_name length is larger than 39 characters because it's maximum length is 50. (https://github.com/django/django/blob/master/django/contrib/auth/models.py#L63) Django automatically prepend "Can change", "Can delete" and "Can add" words to fields' verbose names for name column when inserting rows to auth_permission table so limits the maximum length of a verbose name to 39 character. When syncdb command is run, Django throws a database exception saying "Data truncated for column 'name' at row x" in this case. I think the length of name field is quite low but if you prefer to limit that field to 50 character, Django should not allow verbose name attribute to be larger than 39 character. -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a6266504-6339-46fb-8774-bc4254f24037%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: The length of Permission.name field in django.contrib.auth module is not enough.
Hi Burak, This limitation has been known for a long time. It’s tracked here: https://code.djangoproject.com/ticket/8162 Your second suggestion was implemented a few weeks ago: https://code.djangoproject.com/ticket/18866 -- Aymeric. On 16 nov. 2013, at 19:11, Burak Emre Kabakcı wrote: > The name field in Permission model in django.contrib.auth module causes > problems when one of the fields' verbose_name length is larger than 39 > characters because it's maximum length is 50. > (https://github.com/django/django/blob/master/django/contrib/auth/models.py#L63) > Django automatically prepend "Can change", "Can delete" and "Can add" words > to fields' verbose names for name column when inserting rows to > auth_permission table so limits the maximum length of a verbose name to 39 > character. > When syncdb command is run, Django throws a database exception saying "Data > truncated for column 'name' at row x" in this case. I think the length of > name field is quite low but if you prefer to limit that field to 50 > character, Django should not allow verbose name attribute to be larger than > 39 character. > > -- > 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 django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/a6266504-6339-46fb-8774-bc4254f24037%40googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/808FEB71-322C-4E8F-8715-2378205199A6%40polytechnique.org. For more options, visit https://groups.google.com/groups/opt_out.
Re: Related manager remove() and clear() methods - backwards incompatible changes
On Thursday, October 24, 2013 11:40:37 PM UTC+3, Anssi Kääriäinen wrote: > Here is the full list of changes that potential for breaking user code: > - If related object's default manager has default filtering, then > .remove() and .clear() will not clear those items that are filtered out. > - Reverse ForeignKey .remove() will not use .save() - it will use > .update() - so no model save signals, and overridden model.save() is > missed, too. > - GFK.remove() and GFK.clear() will use queryset.delete() - so > model.delete() is not called anymore (signals are sent in this case as > QuerySet.delete() does that). > > Loic's list of fixes & changes is also a good summary of this ticket: > https://code.djangoproject.com/ticket/21169#comment:9 > I haven't figured any other way to deal with this ticket than just committing the changes. I hope the backwards incompatibilities aren't that severe. The second issue above seems to be the hardest one for users - if you relied on model save signals in your code the code will now be broken *and* you don't have any viable upgrade path if you relied on post_save signal. I am considering addition of pre/post update signals. These signals would give an upgrade path for those who are hit with backwards incompatibility problems from #21169. The signals would of course be a good addition for those who happen to need them. The signals shouldn't affect the performance of your project if you don't use the signals. The idea is that pre_update listeners get a queryset that isn't executed. Accessing that queryset might be costly, but if it isn't accessed, there isn't much cost of adding a pre_update signals. For post_update the signal handler would be given a list of PK values (the original queryset doesn't work for post_update, the update might cause different instances to be returned than was updated, consider qs.filter(deleted=False).update(deleted=True)) The problem here is that if you are updating a lot of rows (millions+), then even fetching the pk value can be too much. Maybe an update(__signals=False) flag could be added? It is also easy to optimize away the pk fetching if there aren't any post_update listeners. Any objections to committing the fixes for https://code.djangoproject.com/ticket/21169? Any feedback for pre/post_update idea? - Anssi -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e37a4bb8-5920-4cc7-adaf-de525a2343d7%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: The length of Permission.name field in django.contrib.auth module is not enough.
Hi Aymeric, Sorry for the duplication. It seems the patch is not merged for 1.6 release. Burak Emre On Saturday, November 16, 2013 8:52:18 PM UTC+2, Aymeric Augustin wrote: > > Hi Burak, > > This limitation has been known for a long time. It’s tracked here: > https://code.djangoproject.com/ticket/8162 > > Your second suggestion was implemented a few weeks ago: > https://code.djangoproject.com/ticket/18866 > > -- > Aymeric. > > > > On 16 nov. 2013, at 19:11, Burak Emre Kabakcı > > > wrote: > > The name field in Permission model in django.contrib.auth module causes > problems when one of the fields' verbose_name length is larger than 39 > characters because it's maximum length is 50. ( > https://github.com/django/django/blob/master/django/contrib/auth/models.py#L63 > ) > Django automatically prepend "Can change", "Can delete" and "Can add" > words to fields' verbose names for name column when inserting rows to > auth_permission table so limits the maximum length of a verbose name to 39 > character. > When syncdb command is run, Django throws a database exception saying > "Data truncated for column 'name' at row x" in this case. I think the > length of name field is quite low but if you prefer to limit that field to > 50 character, Django should not allow verbose name attribute to be larger > than 39 character. > > -- > 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 django-develop...@googlegroups.com . > To post to this group, send email to django-d...@googlegroups.com > . > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/a6266504-6339-46fb-8774-bc4254f24037%40googlegroups.com > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/38a9d7c7-8595-4373-b6bd-a0d41b0dd2aa%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: The length of Permission.name field in django.contrib.auth module is not enough.
On 16 nov. 2013, at 20:25, Burak Emre Kabakcı wrote: > Sorry for the duplication. It seems the patch is not merged for 1.6 release. Indeed, the 1.6 branch was forked from the development branch a few months ago, before that change was committed. -- Aymeric. -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9B2D67D8-95AC-43BD-8914-3DF1FB0640D6%40polytechnique.org. For more options, visit https://groups.google.com/groups/opt_out.
Re: Related manager remove() and clear() methods - backwards incompatible changes
On Nov 17, 2013, at 2:02 AM, Anssi Kääriäinen wrote: > - Reverse ForeignKey .remove() will not use .save() - it will use .update() > - so no model save signals, and overridden model.save() is missed, too. +1 on the pre/post_update signals as they can be useful for a variety of purposes. Although as an upgrade path, anyone who cares about the save signals and save() method can replace rel.remove(*objs) by the following snippet to replicate the old behavior: for obj in objs: obj.fk = None obj.save() This is similar to the recommendation we document for custom delete() methods and QuerySet.delete(): "If you’ve provided a custom delete() method on a model class and want to ensure that it is called, you will need to “manually” delete instances of that model (e.g., by iterating over a QuerySet and calling delete() on each object individually) rather than using the bulk delete() method of a QuerySet." -- Loic -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CFEF3A8E-730D-4AA4-B0E9-BCEB93F34330%40sixmedia.com. For more options, visit https://groups.google.com/groups/opt_out.
