Why doesn't BinaryField use BINARY type?
I had a need to store an encrypted bytestring, and CharField doesn't work. But BinaryField uses LONGBLOB by default (at least on MySQL). Doesn't it make more sense to have a BinaryField equivalent of CharField, and use LONGBLOB for something analogous to TextField? As far as I can tell, the MySQL documentation definitely considers LONGBLOB/BLOB analogous to TEXT. Not sure the best way to approach an improvement, though; add a BytestringField? Would this be best served as a third-party package, or should it be part of Django proper? -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/16540fe7-ea21-4021-a47e-a2ecff7caded%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why doesn't BinaryField use BINARY type?
Maybe the fields from django-mysql help? http://django-mysql.readthedocs.io/en/latest/model_fields/resizable_text_binary_fields.html On Thursday, September 8, 2016 at 10:56:15 AM UTC-4, Chris Foresman wrote: > > I had a need to store an encrypted bytestring, and CharField doesn't work. > But BinaryField uses LONGBLOB by default (at least on MySQL). Doesn't it > make more sense to have a BinaryField equivalent of CharField, and use > LONGBLOB for something analogous to TextField? As far as I can tell, the > MySQL documentation definitely considers LONGBLOB/BLOB analogous to TEXT. > Not sure the best way to approach an improvement, though; add a > BytestringField? Would this be best served as a third-party package, or > should it be part of Django proper? > -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9d0d6c35-ffc1-4fb6-984d-7b9a3b3b671c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Logging config tries too hard
Actually… I'm failing to imagine a scenario where such a change would lead to any bad things: - If `disable_existing_loggers` is True, the incompatibility would manifest itself in Django loggers not being silenced, provided the user has defined a root logger. Which is probably the intended behavior, and I'm having a hard time imagining someone actually relying on it. Most probably users currently work around it either by doing their own config from scratch, or by redefining Django loggers, both of which will continue working after the change. - If `disable_existing_loggers` is explicitly set to False, then we could initialize them as we do now. How does that sound? On Tuesday, September 6, 2016 at 5:44:37 PM UTC-7, Carl Meyer wrote: > > On 09/06/2016 04:57 PM, Ivan Sagalaev wrote: > > I'm > > talking about this function: > > https://github.com/django/django/blob/master/django/utils/log.py#L66 > > > > When `LOGGING_CONFIG` isn't explicitly disabled it first unconditionally > > initializes logging with the hard-coded configuration and then applies a > > user one, if present. And the latter can't really neutralize the effect > > of the former. > > FWIW I agree that the current behavior here is broken and should be > fixed. The design seems to be based in an assumption that > `disable_existing_loggers=True` can "undo" the effects of the previous > config, when it can't, and in fact it does something much nastier -- it > silences all previously-created loggers. > > I clearly recall outlining this issue in a Trac ticket at some point > quite a while ago, but I can't seem to find that ticket now. > > Fixing this in a way that doesn't change logging behavior for projects > upgrading from a previous Django version may be tricky, unless we gate > the effect of the change on (yet another) setting. > > Carl > > -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/78325f82-badf-4e75-9206-be244a8e9cfc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Logging config tries too hard
Hi Ivan, > On Sep 8, 2016, at 9:00 PM, Ivan Sagalaev wrote: > > Actually… I'm failing to imagine a scenario where such a change would lead to > any bad things: You may be right, but it's hard to evaluate that without knowing precisely what change you are envisioning. Can you be more specific about exactly what change you propose? It sounds like you are maybe proposing to decide whether to pre-initialize logging with the built-in default config or not based on whether the user's LOGGING setting has disable_existing_loggers set to True or False? I think that would have the backwards-compatibility properties you outline below, but it doesn't seem to me that it arrives at a very satisfying end result; the system becomes if anything more complex and harder to explain than it is now. I think the best end result would be one where LOGGING simply defines the full config and it is always applied (by Django) exactly once, and the defaults we want are set as the global default for LOGGING, and just documented so that people who want to set LOGGING themselves can easily copy them as a starting point. But we'll need some kind of deprecation path to get there, at least for people who currently have disable_existing_loggers=False, in order to prevent them from suddenly losing the default config. Carl > - If `disable_existing_loggers` is True, the incompatibility would manifest > itself in Django loggers not being silenced, provided the user has defined a > root logger. Which is probably the intended behavior, and I'm having a hard > time imagining someone actually relying on it. Most probably users currently > work around it either by doing their own config from scratch, or by > redefining Django loggers, both of which will continue working after the > change. > > - If `disable_existing_loggers` is explicitly set to False, then we could > initialize them as we do now. > > How does that sound? > >> On Tuesday, September 6, 2016 at 5:44:37 PM UTC-7, Carl Meyer wrote: >> On 09/06/2016 04:57 PM, Ivan Sagalaev wrote: >> > I'm >> > talking about this function: >> > https://github.com/django/django/blob/master/django/utils/log.py#L66 >> > >> > When `LOGGING_CONFIG` isn't explicitly disabled it first unconditionally >> > initializes logging with the hard-coded configuration and then applies a >> > user one, if present. And the latter can't really neutralize the effect >> > of the former. >> >> FWIW I agree that the current behavior here is broken and should be >> fixed. The design seems to be based in an assumption that >> `disable_existing_loggers=True` can "undo" the effects of the previous >> config, when it can't, and in fact it does something much nastier -- it >> silences all previously-created loggers. >> >> I clearly recall outlining this issue in a Trac ticket at some point >> quite a while ago, but I can't seem to find that ticket now. >> >> Fixing this in a way that doesn't change logging behavior for projects >> upgrading from a previous Django version may be tricky, unless we gate >> the effect of the change on (yet another) setting. >> >> Carl > > -- > 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 https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/78325f82-badf-4e75-9206-be244a8e9cfc%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/F00ABFF1-803D-429C-A0B5-0E5E4164D937%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
Re: Logging config tries too hard
> > It sounds like you are maybe proposing to decide whether to pre-initialize > logging with the built-in default config or not based on whether the user's > LOGGING setting has disable_existing_loggers set to True or False? > Yes, I was thinking on my feet and this was one idea I came up with that would allow a sane migration story. But I don't like it either on the same grounds as you, it complicates things just a tad too much. > I think the best end result would be one where LOGGING simply defines the > full config and it is always applied (by Django) exactly once, and the > defaults we want are set as the global default for LOGGING, and just > documented so that people who want to set LOGGING themselves can easily > copy them as a starting point. > I'm actually for that, too. And the defaults should live in global_settings.py, not hard-coded in utils/log.py Funny, it was exactly like that before it's been changed to the current way in 1.5 :-) > But we'll need some kind of deprecation path to get there, at least for > people who currently have disable_existing_loggers=False, in order to > prevent them from suddenly losing the default config. > I'm not familiar with the current deprecation policy in Django. If you can point me to it, I could probably carve some time in the nearby future and prepare a pull request. -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e75d64a4-5205-4ff7-8d2e-c53e9c7ba117%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
