Restart Django logging files once runserver is executed...

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!

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.)

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.

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.

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

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

That’s sounds like exactly what I need. Thank you for the help!

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?

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

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

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

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.

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.

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.

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.