Restart Django logging files once runserver is executed...

Using Django
1

I have django logging configured and working. My question is: Is it possible to wipe the files once the runserver command is run? I am not sure if Django has a built-in feature for this.

Thanks!

2

Iā€™ve never tried this, but the logging configuration documentation gives me the impression that you can specify the filemode parameter in your handler with a 'w' to indicate overwrite rather than append.

Iā€™m guessing that this could be an issue if youā€™re doing this during development, because Iā€™m guessing it would reset the file every time the app was restarted, so if youā€™re using runserver (or runserver_plus) or even uwsgi with file-change detection, itā€™s going to empty the file every time a file is changed. (On the other hand, this may be exactly what you want.)

3

I was trying to find a way to implement this, but only upon running the server so I can start fresh with the logs when I test my project. File mode ā€˜wā€™ would work, but Iā€™m afraid that would wipe the file every time my code hits a new log statement. I wasnā€™t sure if there was a way to state ā€œwipe_on_server_startā€ using the LOGGING dict in the Django settings file.

4

With that being said, I could just make a custom command to wipe the logs, create any necessary db rows for development, and run the server all in one go.

5

You could also wipe the log files at server start by using a custom subclass of FileHandler whose __init__ erases the file.

6

Just as a follow-up, I confirmed that setting 'mode': 'w' on a logging.FileHandler works as I had guessed it might. It will log whatever itā€™s supposed to log, until runserver is restarted - at which point the file is truncated.

So as long as nothing happens to restart runserver, your log will continue to accumulate data.

1 Like
7

Thatā€™s sounds like exactly what I need. Thank you for the help!

8

Another quick question: Where would I put ā€˜modeā€™:ā€˜wā€™? Iā€™m assuming in the LOGGER dict at some point, but would it go under the loggers sub-dict or handlers sub-dict?

9

Itā€™s a handlerā€™s setting. This is an excerpt from my test case this morning that I used to try this:

'handlers': {
    'file': {
        'level': 'DEBUG',
        'class': 'logging.FileHandler',
        'filename': '/var/logs/test/dt_debug.log',
        'formatter': 'verbose',
        'mode': 'w',
    },
 },

Ken

1 Like
10

Yep. That did exactly what I needed. Thanks, man!

11

Thanks for the question! I learned something new today - and I think Iā€™m going to find this handy as well.

Normally, we use the RotatingFileHandler, which can make it difficult to find stuff. With this, I can add a second log file for just the current run so that Iā€™m only looking at log data since the most recent change - and if I ever want to reset the file, I can just touch the settings file to cause it to be reinitialized.

1 Like
12

I was initially using RotatingFileHandler, but also found it hard to navigate between which log file I needed. I decided this approach was more appropriate for a dev environment, especially for testing. I used Django professionally for about 3 years in college and my roommate and I are currently working on a startup :slight_smile: Trying to make sure we keep the dev cycle super clean, concise, and scalable while also paying close attention to test-driven development.

13

Also, Iā€™m not sure if you ever ran into this problem, but I found a way to separate model fields and model functions into separate files while still being able to perform Django queries correctly.

I wanted to organize the files because my model files started to grow very quickly when custom model methods were introduced.

14

Iā€™ve seen someone else here recommend that idea (separate Models from Functions). I donā€™t get it. I donā€™t see the appeal or how it helps. By definition, an object is the data and the methods that operate on that data. The idea of splitting those two just ā€œsmellsā€ bad to me.

Iā€™m much more inclined to split my models.py into a models module and have the __init__.py file import them all from the subordinate files. But we donā€™t even start to consider that until the models.py file gets larger than about 2000 lines.

15

2000 lines i way too much for me, personally. I think it all comes down to personal preference and how the developer plans to support their code base. I personally like the appeal of having an inheritance structure to better organize my files (fields and functions) so i can keep the aforementioned definition of an object true.