I have a question. Your tracker uses threading.locals. Have you ever tried to test this decisiton on a production with more or less big number of users who make changes to your models at the same time?
If you use uwsgi then Django will be just forked by some number of processes (2, 4, 5, whatever you set in your uwsgi settings). So, it means that if you have 1000 online users then, e.g., and 4 forks of Django, then 250 of your 'requests' which you store in thread will go to the same locals and will overwrite each other.
To my mind, it's not serious to tell people that they should use this middleware in their project with full confidence that it will log all changes correctrly.
Hi!
I have a question. Your tracker uses threading.locals. Have you ever tried to test this decisiton on a production with more or less big number of users who make changes to your models at the same time? If you use uwsgi then Django will be just forked by some number of processes (2, 4, 5, whatever you set in your uwsgi settings). So, it means that if you have 1000 online users then, e.g., and 4 forks of Django, then 250 of your 'requests' which you store in thread will go to the same locals and will overwrite each other. To my mind, it's not serious to tell people that they should use this middleware in their project with full confidence that it will log all changes correctrly.