Re: Unneeded index created with unique=True and db_index=False in TextField
On 15/04/15 23:45, Kevin Christopher Henry wrote: This issue was the subject of https://code.djangoproject.com/ticket/24082. There, the accepted (but not implemented) solution is the same as suggested here: allowing the user to opt out of the creation of the additional index with `db_index=False`. Ah, sorry I didn't see that. That solution would certainly work. Thanks. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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/552EED1D.3060106%40googlemail.com. For more options, visit https://groups.google.com/d/optout.
Re: Unneeded index created with unique=True and db_index=False in TextField
This issue was the subject of https://code.djangoproject.com/ticket/24082. There, the accepted (but not implemented) solution is the same as suggested here: allowing the user to opt out of the creation of the additional index with `db_index=False`. On Wednesday, April 15, 2015 at 2:11:25 PM UTC-4, Some Developer wrote: > > On 15/04/15 18:22, Tim Graham wrote: > > #19441 is the ticket where it was decided that unique=True implies a > > database index. The documentation says, > > > > "Note that when ``unique`` is ``True``, you don't need to specify > > > > `Field.db_index`, because ``unique`` implies the creation of an index." > > > > Understood. I just want to be able to stop the creation of the index in > some way. Whether that be via db_index=False or some other new method. > > I would have thought that the creation of the index would be optional. I > understand that the default it to create the index and that is fine for > the vast majority of cases (in fact until I hit this little problem I > didn't care one way or another) but a user should have the option to > tell Django not to create the index if they are sure they know what they > are doing. > > > Unless we decide that is wrong, I think the correct condition to solve > > the issue would be more like `field.db_index orfield.unique and > > field.db_index is not False`. We might also have to change the default > > keyword of Field from False to None so we know the difference between > > "unspecified" and False. > > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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/7e481c16-ec13-4454-88b7-369c725ac30f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Unneeded index created with unique=True and db_index=False in TextField
On 15/04/15 18:22, Tim Graham wrote: #19441 is the ticket where it was decided that unique=True implies a database index. The documentation says, "Note that when ``unique`` is ``True``, you don't need to specify `Field.db_index`, because ``unique`` implies the creation of an index." Understood. I just want to be able to stop the creation of the index in some way. Whether that be via db_index=False or some other new method. I would have thought that the creation of the index would be optional. I understand that the default it to create the index and that is fine for the vast majority of cases (in fact until I hit this little problem I didn't care one way or another) but a user should have the option to tell Django not to create the index if they are sure they know what they are doing. Unless we decide that is wrong, I think the correct condition to solve the issue would be more like `field.db_index orfield.unique and field.db_index is not False`. We might also have to change the default keyword of Field from False to None so we know the difference between "unspecified" and False. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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/552EA9BD.1030001%40googlemail.com. For more options, visit https://groups.google.com/d/optout.
Re: Unneeded index created with unique=True and db_index=False in TextField
#19441 is the ticket where it was decided that unique=True implies a database index. The documentation says, "Note that when ``unique`` is ``True``, you don't need to specify`Field.db_index`, because ``unique`` implies the creation of an index." Unless we decide that is wrong, I think the correct condition to solve the issue would be more like `field.db_index or field.unique and field.db_index is not False`. We might also have to change the default keyword of Field from False to None so we know the difference between "unspecified" and False. On Wednesday, April 15, 2015 at 12:39:53 PM UTC-4, Some Developer wrote: > > On 15/04/15 03:37, Curtis Maloney wrote: > > Was the OP referring to the unique index, or the index created for the > > LIKE lookups? > > > > I was involved in a discussion recently [was there something on list > > too?] wanting to be able to opt-out of the second index because they > > knew they didn't need it, and it was _huge_ on their database. > > > > -- > > C > > > > The index created for the LIKE lookups. > > The index name even has _like appended on to the name so I'm pretty sure > that this is the problem at hand. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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/c77a48fb-470c-47f6-94b5-cff1fdbfbe17%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Unneeded index created with unique=True and db_index=False in TextField
On 15/04/15 03:37, Curtis Maloney wrote: Was the OP referring to the unique index, or the index created for the LIKE lookups? I was involved in a discussion recently [was there something on list too?] wanting to be able to opt-out of the second index because they knew they didn't need it, and it was _huge_ on their database. -- C The index created for the LIKE lookups. The index name even has _like appended on to the name so I'm pretty sure that this is the problem at hand. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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/552E944D.7050500%40googlemail.com. For more options, visit https://groups.google.com/d/optout.
Re: Why deprecate the ability to reverse using the Python path?
Thank you Graham. I will talk with my team mates again. Moving to URLs with names is no good solution for us. But maybe using the view methods itself. Since a lazy reverse() exists since some releases now, removing the whole string magic might be a good idea. Thanks to all django developers for your constant updates. It's just hard to keep up with your pace :-) Am Mittwoch, 15. April 2015 12:51:25 UTC+2 schrieb Tim Graham: > > Please see the ticket and release notes: > https://code.djangoproject.com/ticket/22384 > > https://docs.djangoproject.com/en/1.8/releases/1.8/#passing-a-dotted-path-to-reverse-and-url > > If you want to continue using dotted paths, you might be able to create a > custom url() function that assigns a name using the view's path and use > that in your urlpatterns instead of django.conf.urls.url(). > > On Wednesday, April 15, 2015 at 4:19:47 AM UTC-4, guettli wrote: >> >> Today I realized that the ability to reverse using the Python path gets >> deprecated >> >> My source: >> https://docs.djangoproject.com/en/1.8/ref/urlresolvers/#reverse >> >> Imagine you have a very clear directory structure and everyone knows this >> in >> your company. >> >> The name of an url pattern is redundant. I like to avoid redundancy (DRY). >> >> I don't see the reasons behind this. >> >> The security issues are already solved: >> https://www.djangoproject.com/weblog/2014/apr/21/security/#s-issue-unexpected-code-execution-using-reverse >> >> Please tell me the reason. >> >> One work around this would be to give each view the name of the import >> path: name="common_structure.foo.bar" >> And if you don't allow dots: name="common_structure/foo/bar" >> But this looks not dirty. >> >> >> >> >> >> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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/7b026328-b554-46de-a324-59d18870c413%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why deprecate the ability to reverse using the Python path?
Please see the ticket and release notes: https://code.djangoproject.com/ticket/22384 https://docs.djangoproject.com/en/1.8/releases/1.8/#passing-a-dotted-path-to-reverse-and-url If you want to continue using dotted paths, you might be able to create a custom url() function that assigns a name using the view's path and use that in your urlpatterns instead of django.conf.urls.url(). On Wednesday, April 15, 2015 at 4:19:47 AM UTC-4, guettli wrote: > > Today I realized that the ability to reverse using the Python path gets > deprecated > > My source: https://docs.djangoproject.com/en/1.8/ref/urlresolvers/#reverse > > Imagine you have a very clear directory structure and everyone knows this > in > your company. > > The name of an url pattern is redundant. I like to avoid redundancy (DRY). > > I don't see the reasons behind this. > > The security issues are already solved: > https://www.djangoproject.com/weblog/2014/apr/21/security/#s-issue-unexpected-code-execution-using-reverse > > Please tell me the reason. > > One work around this would be to give each view the name of the import > path: name="common_structure.foo.bar" > And if you don't allow dots: name="common_structure/foo/bar" > But this looks not dirty. > > > > > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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/a27d5e33-a016-4377-bc8b-ef214213aacb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Why deprecate the ability to reverse using the Python path?
Today I realized that the ability to reverse using the Python path gets deprecated My source: https://docs.djangoproject.com/en/1.8/ref/urlresolvers/#reverse Imagine you have a very clear directory structure and everyone knows this in your company. The name of an url pattern is redundant. I like to avoid redundancy (DRY). I don't see the reasons behind this. The security issues are already solved: https://www.djangoproject.com/weblog/2014/apr/21/security/#s-issue-unexpected-code-execution-using-reverse Please tell me the reason. One work around this would be to give each view the name of the import path: name="common_structure.foo.bar" And if you don't allow dots: name="common_structure/foo/bar" But this looks not dirty. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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/4d36be10-847a-40f5-9421-5d6e0d6d865c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
