Det er normalt en forkert idé at placere relaterede data i forskellige Redis-databaser. Der er næsten ingen fordel sammenlignet med at definere navnerum ved hjælp af nøglenavnekonventioner (ingen ekstra detaljering med hensyn til sikkerhed, vedholdenhed, udløbsstyring osv. ...). Og en stor ulempe er, at klienterne manuelt skal håndtere udvælgelsen af den korrekte database, hvilket er fejludsat for klienter, der målretter mod flere databaser på samme tid.
Nu, hvis du stadig ønsker at bruge flere databaser, er der en måde at få det til at fungere med redis-py og Lua scripting.
redis-py definerer ikke en wrapper for SELECT-kommandoen (bruges normalt til at skifte den aktuelle database), på grund af den underliggende trådsikre forbindelsespoolimplementering. Men intet forhindrer dig i at kalde SELECT fra et Lua-script.
Overvej følgende eksempel:
$ redis-cli
SELECT 0
SET mykey db0
SELECT 1
SET mykey db1
Følgende script viser værdien af mykey i de 2 databaser fra den samme klientforbindelse.
import redis
pool = redis.ConnectionPool(host='localhost', port=6379, db=0)
r = redis.Redis(connection_pool=pool)
lua1 = """
redis.call("select", ARGV[1])
return redis.call("get",KEYS[1])
"""
script1 = r.register_script(lua1)
lua2 = """
redis.call("select", ARGV[1])
local ret = redis.call("get",KEYS[1])
redis.call("select", ARGV[2])
return ret
"""
script2 = r.register_script(lua2)
print r.get("mykey")
print script2( keys=["mykey"], args = [1,0] )
print r.get("mykey"), "ok"
print
print r.get("mykey")
print script1( keys=["mykey"], args = [1] )
print r.get("mykey"), "misleading !!!"
Scriptet lua1 er naivt:det vælger bare en given database, før det returnerer værdien. Dens brug er vildledende, fordi den aktuelle database, der er knyttet til forbindelsen, er ændret efter dens udførelse. Gør ikke dette.
Script lua2 er meget bedre. Det tager måldatabasen og den aktuelle database som parametre. Den sørger for, at den aktuelle database genaktiveres inden afslutningen af scriptet, så den næste kommando, der anvendes på forbindelsen, stadig kører i den korrekte database. Desværre er der ingen kommando til at gætte den aktuelle database i Lua-scriptet, så klienten skal sørge for det systematisk. Bemærk venligst, at Lua-scriptet skal nulstille den aktuelle database til sidst, uanset hvad der sker (selv i tilfælde af tidligere fejl), så det gør komplekse scripts besværlige og akavede.