Re: To keep or not to keep: logging of undefined template variables
Apparently there is number of errors in admin templates. I suggest to fix the templates. I my experience, the most cases are missing if statements or missing context variables. These can be fixed very easily and produce cleaner templates. I consider this much better solution than just ignoring error messages. As Anthony suggested, the main problem is more often the fuzziness of the messages, which do not often properly state template, line or expression which is incorrect. This makes it difficult to resolve them in some cases. Vlastik Dne čtvrtek 24. srpna 2017 17:21:38 UTC+2 Tim Graham napsal(a): > > We received a report that shows the large number of undefined variable > warnings when rendering an admin changelist page [0]. > > I'm still not sure what the solution should be, but I created #28526 [1] > to track this problem: finding a remedy to the problem of verbose, often > unhelpful logging of undefined variables. > > I don't think "the end goal of errors raising when using undefined > variables" is feasible. My sense is that relying on the behavior of > undefined variables is too entrenched in the Django template language to > change it at this point. (If someone wanted to try to fix all the warnings > in the admin templates, that might provide a useful data point). See the > "Template handling of undefined variables" thread [2] for a longer > discussion. > > [0] https://code.djangoproject.com/ticket/28516 > [1] https://code.djangoproject.com/ticket/28526 > [2] > https://groups.google.com/d/topic/django-developers/LT5ESP0w0gQ/discussion > > On Tuesday, June 20, 2017 at 4:12:52 AM UTC-4, Anthony King wrote: >> >> -1 for removing logs. Like Vlastimil, it's helped me spot a couple of >> stray bugs. >> >> What I'd actually like to see is this becoming stricter, with the end >> goal of errors raising when using undefined variables. >> >> For the verbosity, perhaps there's a middle ground? only log once per >> variable access per template context, and provide a formatter that will >> clean up the output? >> >> I believe in debug mode, you have access to line numbers and character >> positions, so the final output could look something like this: >> >> `` >> some_app/home.html:32:24: Undefined variable: *missing_variable* >> `` >> >> I'm unsure how much effort this would take, but it would definitely make >> the logging a lot more user + developer friendly. >> >> On 20 June 2017 at 08:48, Vlastimil Zíma wrote: >> >>> -1 to the removal. I was annoyed by the logging at first, but then I >>> started to clean individual logs. Half way through, I found several usages >>> of long removed variables, one unused template (as a side effect) and I >>> updated several views to always provide defined context variables. >>> >>> All in all, I consider the warnings very useful for a cleaning, though I >>> wouldn't be against an option to silence them. Which can already by >>> accomplished by LOGGING, can't it? >>> >>> Vlastik >>> >>> Dne neděle 26. března 2017 11:14:23 UTC+2 Melvyn Sopacua napsal(a): On Thursday 16 March 2017 12:03:07 Tim Graham wrote: > Ticket #18773 [0] added logging of undefined template variables in > Django 1.9 [1], however, I've seen several reports of users finding > this logging more confusing than helpful. With channels hitting 2.0 and the already large stack of moving parts surrounding Django you need some basic system administration skills and programming experience to work with the system. And there are quite a few examples to link to from the user's list that deal with those moving parts rather then Django itself. It is not an application that you download, install and run. An introduction "What you need to know before starting Django" would help a lot in this respect and explaining the noisiness of some logging belongs in there. Because it *is* useful if you defined that variable to True in your settings, and it's working in all projects but this one. It could be there's an extra piece of context middleware that uses the same name and deletes the variable from the context. It could be there's a Mixin missing in the view hierarchy. Or a typo you don't notice anymore after plowing through 20+ included template bits. Noisy logging is exactly what you want when debugging. It should log things that may be working as designed, especially things that are ambiguous (like undefined and false). Another thing is that logging is the ugly duckling of Django. It's not mentioned much if at all in the tutorial. It is not mentioned at all in "How to write reusable apps" and it shows in the eco system. It's like finding a diamond when an app actually has logging implemented. But it also means that novice users
Re: To keep or not to keep: logging of undefined template variables
If anyone is interested, I've cleaned the errors in admin templates: Ticket: https://code.djangoproject.com/ticket/28529 PR: https://github.com/django/django/pull/8973 The fixes are quite simple. The biggest problem is sometimes to find out, in which template the bug actually appears. Vlastik Dne pátek 25. srpna 2017 9:28:30 UTC+2 Vlastimil Zíma napsal(a): > > Apparently there is number of errors in admin templates. I suggest to fix > the templates. I my experience, the most cases are missing if statements or > missing context variables. These can be fixed very easily and produce > cleaner templates. I consider this much better solution than just ignoring > error messages. > > As Anthony suggested, the main problem is more often the fuzziness of the > messages, which do not often properly state template, line or expression > which is incorrect. This makes it difficult to resolve them in some cases. > > Vlastik > > Dne čtvrtek 24. srpna 2017 17:21:38 UTC+2 Tim Graham napsal(a): >> >> We received a report that shows the large number of undefined variable >> warnings when rendering an admin changelist page [0]. >> >> I'm still not sure what the solution should be, but I created #28526 [1] >> to track this problem: finding a remedy to the problem of verbose, often >> unhelpful logging of undefined variables. >> >> I don't think "the end goal of errors raising when using undefined >> variables" is feasible. My sense is that relying on the behavior of >> undefined variables is too entrenched in the Django template language to >> change it at this point. (If someone wanted to try to fix all the warnings >> in the admin templates, that might provide a useful data point). See the >> "Template handling of undefined variables" thread [2] for a longer >> discussion. >> >> [0] https://code.djangoproject.com/ticket/28516 >> [1] https://code.djangoproject.com/ticket/28526 >> [2] >> https://groups.google.com/d/topic/django-developers/LT5ESP0w0gQ/discussion >> >> On Tuesday, June 20, 2017 at 4:12:52 AM UTC-4, Anthony King wrote: >>> >>> -1 for removing logs. Like Vlastimil, it's helped me spot a couple of >>> stray bugs. >>> >>> What I'd actually like to see is this becoming stricter, with the end >>> goal of errors raising when using undefined variables. >>> >>> For the verbosity, perhaps there's a middle ground? only log once per >>> variable access per template context, and provide a formatter that will >>> clean up the output? >>> >>> I believe in debug mode, you have access to line numbers and character >>> positions, so the final output could look something like this: >>> >>> `` >>> some_app/home.html:32:24: Undefined variable: *missing_variable* >>> `` >>> >>> I'm unsure how much effort this would take, but it would definitely make >>> the logging a lot more user + developer friendly. >>> >>> On 20 June 2017 at 08:48, Vlastimil Zíma wrote: >>> -1 to the removal. I was annoyed by the logging at first, but then I started to clean individual logs. Half way through, I found several usages of long removed variables, one unused template (as a side effect) and I updated several views to always provide defined context variables. All in all, I consider the warnings very useful for a cleaning, though I wouldn't be against an option to silence them. Which can already by accomplished by LOGGING, can't it? Vlastik Dne neděle 26. března 2017 11:14:23 UTC+2 Melvyn Sopacua napsal(a): > > On Thursday 16 March 2017 12:03:07 Tim Graham wrote: > > > Ticket #18773 [0] added logging of undefined template variables in > > > Django 1.9 [1], however, I've seen several reports of users finding > > > this logging more confusing than helpful. > > > > With channels hitting 2.0 and the already large stack of moving parts > surrounding Django you need some basic system administration skills and > programming experience to work with the system. And there are quite a few > examples to link to from the user's list that deal with those moving > parts > rather then Django itself. It is not an application that you > download, install and run. > > > > An introduction "What you need to know before starting Django" would > help a lot in this respect and explaining the noisiness of some logging > belongs in there. > > > > Because it *is* useful if you defined that variable to True in your > settings, and it's working in all projects but this one. It could be > there's an extra piece of context middleware that uses the same name and > deletes the variable from the context. It could be there's a Mixin > missing > in the view hierarchy. Or a typo you don't notice anymore after plowing > through 20+ included template bits. > > > > Noisy logging is exactly what you want when debugging. It should l
Feature request: Allow to process data-migrations after flush
Currently it's somewhat difficult to process initial data after a flush. You will need to fake the database state... In my case I'm creating all tables of the project with the migration 0001 and populating with initial data on migration 0002. After spending a time looking for solutions found that I could achieve the desired result with: python manage.py flush python manage.py migrate app 0001 --fake python manage.py migrate app 0002 python manage.py migrate app --fake While this works might be confusing (and risky), since django is indeed providing data-migrations, makes sense that after flushing the database one could repopulate the database easily. Since making 'flush' not to delete the data-migrations data seems overly complicated or simply impossible in real-world, makes sense to be able to --force a particular migration without touching others. Hope to read your comments. Greetings! -- 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/bcb956ac-54b8-22e4-544e-a65c84647bdb%40solucioneslibres.com. For more options, visit https://groups.google.com/d/optout.
