richfitz
Consider mangling keys selectively
Could we do a quick check on keys (either key == make.names(key) or grepl(pattern = "^([a-z]|[0-9]|_|\\.)+$", ignore.case = TRUE)) before even trying to mangle keys? Maybe for storr_rds(mangle_key = "selective")?
I think this is a much better solution to #44 than #87. For certain drake workflows, half the overhead is from mangling keys, and the overwhelming majority of keys do not even need to be mangled. (They only contain alphanumerics, dots, and underscores.) It is a shame to punish all the well-behaved keys for the sake of a delinquent few.
Somehow, we would need to ensure uniqueness and indicate where decoding is needed. Maybe we could attach prefixes "e" and "n" to encoded and non-encoded keys, respectively.
I don't love this idea I'm afraid. But if you can work up a PR that doesn't seem overly complicated and preserves the existing behaviours by default I would be willing to consider it for sure. [edit to add: the reason my this doesn't grab me immediately is it looks like a lot of logic - the more logic, the harder the testing, and the harder the maintenance. But if the implementation ends up looking straightforward then that would make me relaxed about it]
A further possibility might be to allow a generic "custom mangling" function - then you can hold this logic in drake?
After more thought and development, I figured out that I may not need this feature after all. For drake, it may actually make more sense to pre-encode all the file paths and set mangle_key to FALSE for new storrs. I am working on an implementation now.
ok, let me know - sorry for the slow responses recently, but I'm hoping to get more time on this next year
Sounds great. I actually like how this turned out. #90 really needed a period of reflection.
I hope we both get more time next year.
More about the new direction I am trying: https://github.com/ropensci/drake/issues/630
https://github.com/ropensci/drake/issues/630 turns out to solve the issue for drake. The implementation comes with a generous speed improvement, and it cleans up the way file paths are represented internally. I no longer have a use for #88, #89, or #90. Please feel free to close.