contributte / redis

:floppy_disk: Redis (predis) for Nette Framework (@nette)

Home Page:https://contributte.org/packages/contributte/redis.html

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

sessions + cache possible issue in one connection

dakorpar opened this issue · comments

I'm looking into code and thinking what to do when U're using redis for both sessions and cache...
What happens if you're on one connection and clear cache?
From what i see all sessions will be lost as well, since flushAll is being called
currently I did this:

    connection:
        default:
            uri: tcp://127.0.0.1:6379
            sessions: false
            storage: true
            options: ['parameters': ['database': 1]
        session:
            uri: tcp://127.0.0.1:6379
            sessions: true
            storage: false
            options: ['parameters': ['database': 2]]

and this works fine, but there's nothing in README that would explain this, so just wondering should we add this to docs,
or actually also add some checks and not even allow such config, or to automatically force someone to choose db?

@dakorpar Doesn't flushall clear all databases?

@fmasa you're apsolutelly correct. I didn't even check and didn't work much with redis directly 😸
I assumed it's clearing only current db
I've created PR https://github.com/contributte/redis/pull/15/files
That is what was probably causing logout issues on my project

I still believe it would be a good thing to mention not to use same database after this PR is merged, otherwise people can assume it won't clear sessions every time they clear cache and let's be honest, this is never wanted behaviour

Good catch, thanks. Docs PR is also welcome.

I think we can make this even more robust. We can i.e. prefix sessions and cache keys (i.e. cache entries will ve stored as cache:<key> and session entries as session:<session_key> and clean keys using cache:* pattern instead of using flushdb. Flushing whole db can be a problem when using Redis Cluster as there is only one DB per cluster.

@f3l1x I think it's a good option.
@fmasa will you prepare PR for that, or I have to do it?
It's also breaking change, ...

I like it too. Would you guys prepare PR with tests please? I think we can use github actions services and test it on real redis.

Sure, I'll prepare it.