A session record will get written to the DB if you:
- Just access (read from) request.session
- Just access request.user (which underneath, is also accessing request.session)
I agree that this in't a great behavior, but it is what I observe in a lot of trial and error tests.
@dstufft - yes, I would think accessing request.user wouldn't create a new session row, but that is not the case. When this code happens:
user_id = request.session[SESSION_KEY]
Then the session gets created in the db, even though that code will eventually bomb out with a key error for the SESSION_KEY.
I'd encourage others to set this stuff up and try it, how I would think things should work are not how things actually work ;) within django's session middleware.
A session record will get written to the DB if you:
- Just access (read from) request.session
- Just access request.user (which underneath, is also accessing request.session)
A good general intro is at http:// stackoverflow. com/questions/ 4444758/ huge-django- session- table-normal- behaviour- or-bug
The db session backend is forcing a session row to be created at: /github. com/django/ django/ blob/master/ django/ contrib/ sessions/ backends/ db.py#L29
https:/
This essentially is saying if we couldn't find any session info, the db backend will generate a session ID for the user and write a row into the DB.
I agree that this in't a great behavior, but it is what I observe in a lot of trial and error tests.
@dstufft - yes, I would think accessing request.user wouldn't create a new session row, but that is not the case. When this code happens: session[ SESSION_ KEY]
user_id = request.
Then the session gets created in the db, even though that code will eventually bomb out with a key error for the SESSION_KEY.
I'd encourage others to set this stuff up and try it, how I would think things should work are not how things actually work ;) within django's session middleware.