Open lazerwalker opened 2 years ago
Manually writing scripts is more work than I want. The built-in redis dump command requires disk access (which we don't have), so we'd basically be looking at manually creating an allow-list of all keys we should serialize to disk. I think that's still less work than a persistence layer consisting of both a db and redis.
Next steps for me: investigate how disparate our use of keys are. I know 100% of our key use is limited to our one redis file, but the fact that we use runtime-generated keys (i.e. based on user IDs and room names) might complicate things.
That does not require being clever. Redis has a KEYS *
command that dumps all key names. There's no nifty function to get all values, but for an infrequently-run dump script it's reasonable to iterate through that list of keys and perform a bunch of GETs.
We're using KEYS
to power the dynamic room editor. Which is just to confirm that's possible.
It would be great for many reasons if our data stayed constant from year to year.
A few potential ways to handle this:
My gut instinct is the middle option is the right complexity sweet spot: at the end of each year, we save the state of the social space, and next year we restore it. Ideally restoring is easy enough that it's not a problem to do mid-year as we resume dev. Also has the benefit of letting us wipe all dev work before the event itself. But open to suggestions.