-
Notifications
You must be signed in to change notification settings - Fork 11
Custom key mangling #89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
richfitz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've suggested a fairly substantial change in one of the comments - would you mind having a go at that?
R/utils.R
Outdated
| } | ||
| } | ||
|
|
||
| assert_function <- function(x, name = deparse(substitute(x))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This already exists on line 53 😁
| ##' @param default_namespace Default namespace (see | ||
| ##' \code{\link{storr}}). | ||
| ##' | ||
| ##' @param mangle_key_encode Optional function for mangling keys. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am thinking about the interface here and I think that we should offer a single argument here; the existing mangle_key which can take string arguments
none- equivalent to the currentFALSEbase64- equivalent to the currentTRUExxxx- a key for a "registered" mangler
Then we need a new function:
register_mangler <- function(name, encode, decode, overwrite = FALSE) {...}
which adds a new mangling strategy. Then drake would call as part of initialisation (.onLoad), storr::register_mangler("drake::lazy_base64", drake::lazy_base64_encode, drake::lazy_base64_decode)
We'll save the functions into the class much as you have here.
My thinking here is that storr archives need to be openable by previous and future versions of storr, and that the options should be saved into the archive itself to avoid corrupting them (there's some fairly nasty logic going on already for that).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that idea the best so far. Implementation and back compatibility are much easier this way. I will start a new branch and PR tomorrow.
| write_if_missing("TRUE", driver_rds_config_file(path, "compress")) | ||
| write_if_missing("md5", driver_rds_config_file(path, "hash_algorithm")) | ||
| write_if_missing( | ||
| deparse(mangle_key_encode), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One downside of this approach is that the deparse route is not going to result in something that can be parsed back out as a usable function later
To follow up on #88 (comment), this PR proposes custom
mangle_key_encodeandmangle_key_decodefunctions for the RDS driver constructor. It is not quite working yet (I find it difficult to interact withtest-driver.R) but does demonstrate what I am proposing.