Object cache driver that saves objects using R's native
serialized file format (see saveRDS) on the
filesystem.
storr_rds(path, compress = NULL, mangle_key = NULL, mangle_key_pad = NULL, hash_algorithm = NULL, default_namespace = "objects") driver_rds(path, compress = NULL, mangle_key = NULL, mangle_key_pad = NULL, hash_algorithm = NULL)
| path | Path for the store. |
|---|---|
| compress | Compress the generated file? This saves a small amount of space for a reasonable amount of time. |
| mangle_key | Mangle keys? If TRUE, then the key is encoded using base64 before saving to the filesystem. See Details. |
| mangle_key_pad | Logical indicating if the filenames created
when using |
| hash_algorithm | Name of the hash algorithm to use. Possible
values are "md5", "sha1", and others supported by
|
| default_namespace | Default namespace (see
|
The mangle_key argument will run each key that is created
through a "base 64" encoding. This means that keys that include
symbols that are invalid on filesystems (e.g, "/", ":") will be
replaced by harmless characters. The RFC 4648 dialect is used
where "-" and "_" are used for character 62 and 63 (this differs
from most R base64 encoders). This mangling is designed to be
transparent to the user -- the storr will appear to store things
with unmangled keys but the names of the stored files will be
different.
Note that the namespace is not mangled (at least not yet) so needs to contain characters that are valid in a filename.
Because the actual file will be stored with mangled names it is
not safe to use the same path for a storr with and without
mangling. So once an rds storr has been created its "mangledness"
is set. Using mangle_key = NULL uses whatever mangledness
exists (or no mangledness if creating a new storr).
Some file synchronisation utilities like dropbox can create file
that confuse an rds storr (e.g.,
"myobject (Someone's conflicted copy)". If
mangle_key is FALSE these cannot be detected but at
the same time are not a real problem for storr. However, if
mangle_key is TRUE and keys are base64 encoded then
these conflicted copies can break parts of storr.
If you see a warning asking you to deal with these files, please delete the offending files; the path will be printed along with the files that are causing the problem.
Alternatively, you can try (assuming a storr object st)
running
st$driver$purge_corrupt_keys()
which will delete corrupted keys with no confirmation. The
messages that are printed to screen will be printed by default at
most once per minute per namespace. You can control this by
setting the R option storr.corrupt.notice.period - setting
this to NA suppresses the notice and otherwise it is
interpreted as the number of seconds.
# Create an rds storr in R's temporary directory: st <- storr_rds(tempfile()) # Store some data (10 random numbers against the key "foo") st$set("foo", runif(10)) st$list()#> [1] "foo"# And retrieve the data: st$get("foo")#> [1] 0.68016292 0.49884561 0.64167935 0.66028435 0.09602416 0.76560016 #> [7] 0.76967480 0.99071231 0.97052090 0.38918276# Keys that are not valid filenames will cause issues. This will # cause an error:# NOT RUN { st$set("foo/bar", letters) # }# The solution to this is to "mangle" the key names. Storr can do # this for you: st2 <- storr_rds(tempfile(), mangle_key = TRUE) st2$set("foo/bar", letters) st2$list()#> [1] "foo/bar"st2$get("foo/bar")#> [1] "a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l" "m" "n" "o" "p" "q" "r" "s" #> [20] "t" "u" "v" "w" "x" "y" "z"# Behind the scenes, storr is safely encoding the filenames with base64: dir(file.path(st2$driver$path, "keys", "objects"))#> [1] "Zm9vL2Jhcg"# Clean up the two storrs: st$destroy() st2$destroy()