Der er mindst 3 forskellige måder at gøre det på, hver har sine egne fordele og ulemper.
Den første tilgang er at bruge ikke-atomisk ad hoc-scanning af træet til at identificere og ugyldiggøre (slette) træets 2. niveau (1. sæt tilpasninger). For at gøre det skal du bruge et hierarisk navngivningsskema for din Hashs felter og gentage dem ved hjælp af HSCAN . Hvis du for eksempel antager, at din Hashs nøglenavn er produktets ID (f.eks. ProductA), vil du bruge noget som '0001:0001' som feltnavn for den første tilpasnings første version, '0001:0002' for dens anden version og og så videre. På samme måde ville '0002:0001' være den 2. tilpasning 1. version, osv... Find alle versioner af tilpasning 42, brug HSCAN ProductA 0 MATCH 0042:* , HDEL felterne i svaret, og gentag indtil markøren nuller.
Den modsatte tilgang er proaktivt at "indeksere" hver tilpasnings versioner, så du kan hente dem effektivt i stedet for at udføre Hash'ens fulde scanning. Vejen til det er at bruge Redis' sæt - du beholder et sæt med alle feltnavnene for et givent produkts version. Versioner kan enten være sekventielle (som i mit eksempel) eller noget andet, så længe de er unikke. Omkostningerne er at vedligeholde disse indekser - hver gang du tilføjer eller fjerner et produkts tilpasning og/eller version, skal du bevare overensstemmelse med disse sæt. For eksempel ville oprettelsen af en version være noget i stil med:
HSET ProductA 0001:0001 "<customization 1 version 1 JSON payload"
SADD ProductA:0001 0001
Bemærk, at disse to operationer skal være i en enkelt transaktion (dvs. brug en MULTI\EXEC blok eller EVAL et Lua-script). Når du har denne opsætning, er ugyldiggørelse af en tilpasning blot et spørgsmål om at ringe til SMEMBERS på det relevante sæt og sletning af versionerne i det fra Hash (og selve sættet). Det er dog vigtigt at bemærke, at læsning af alle medlemmer fra et stort sæt kan være tidskrævende - 1K medlemmer er ikke så slemt, men for større sæt er der SSCAN .
Til sidst kan du overveje at bruge et sorteret sæt i stedet for en Hash. Selvom det måske er mindre intuitivt i dette tilfælde, vil det sorterede sæt lade dig udføre alle de operationer, du har brug for. Prisen for at bruge det er imidlertid den øgede kompleksitet af O(logN) til at tilføje/fjerne/læse sammenlignet med Hash'ens O(1), men givet tallene er forskellen ikke signifikant.
For at frigøre det sorterede sæts kraft skal du bruge leksikografisk rækkefølge, så alle medlemmer af det sorterede sæt skal have samme score (brug f.eks. 0). Hvert produkt vil blive repræsenteret af et sorteret sæt, ligesom med Hash. Medlemmerne af sættet er ækvivalenter til Hash-feltet, nemlig tilpasningernes versioner. "Tricket" er at konstruere medlemmerne på en måde, der giver dig mulighed for at udføre rækkeviddesøgninger (eller niveau-2 ugyldiggørelser om du vil). Her er et eksempel på, hvordan det skal se ud (bemærk, at her er nøglen ProductA ikke en Hash, men et Sorteret Sæt):
ZADD ProductA 0 0001:0001:<JSON>
For at læse en tilpasningsversion skal du bruge ZRANGEBYLEX ProductA [0001:0001: [0001:0001:\xff og del JSON'en fra svaret og for at fjerne en hel tilpasning, brug ZREMRANGEBYLEX .