Re: Races in sessions

Thinking out loud: You can't just lock the session when you think you have a critical section of code in a view because the session data is stored in one field in the database, and is *completely overwritten* on write. Consider this case: Thread A: Read session data Thread B: Open transaction,

Add a stable and documented setting to add files to the runserver watcher

I am working on a graphQL project which uses django and ariadne . This package supports loading your graphQL schema from external **.graphql *files. While developing the schema, I

Re: Races in sessions

Stephen - you're right that a constraint is the best way to enforce consistency in the DB. That doesn't fit every use case for sessions though - people use Django's built-ins with many different kinds of data stores that don't support locking or constraint semantics, such as remote API's. Matt -

Re: Races in sessions

The way I'd solve this example is to create a unique constraint/index in the DB. The session check gives a quick pre-check, but in the event of a race the DB enforces absolute consistency. If the constraint isn't possible or is too complex, then your "SELECT... FOR UPDATE" belongs on the check

Races in sessions

The "post_comment" example of sessions appears to be incorrect: https://docs.djangoproject.com/en/3.1/topics/http/sessions/#examples Imagine two HTTP requests coming in at the same time, both seeing that "has_commented" is False, and then both create a comment and set the session variable to