The ClientSession table has a M2M to itself, to support client sessions with different keys but which we know to be linked, (even though the Client may still be anonymous/null). For instance, the Omnispective user's application may return the client a new session upon logging in; this session should be linked to that which the client was using before logging in. It's possible that this will be useful in other instances, as well.
We may explore the same feature without the M2M — instead, we could make ClientSession.client non-null, but make Client.username null or optional (empty string), and fill in the username once we have it. This may be simpler/lighter-weight… or not.
Regardless, though the ClientSession.linked_sessions table exists, it is unused, and this feature as yet unimplemented.
The
ClientSession
table has a M2M to itself, to support client sessions with different keys but which we know to be linked, (even though theClient
may still be anonymous/null). For instance, the Omnispective user's application may return the client a new session upon logging in; this session should be linked to that which the client was using before logging in. It's possible that this will be useful in other instances, as well.We may explore the same feature without the M2M — instead, we could make
ClientSession.client
non-null, but makeClient.username
null or optional (empty string), and fill in the username once we have it. This may be simpler/lighter-weight… or not.Regardless, though the
ClientSession.linked_sessions
table exists, it is unused, and this feature as yet unimplemented.