The PR for additional fanc_meta (https://github.com/natverse/coconatfly/pull/22) gives one pattern, where we just return accept a path to a file on disk (tsv/feather) or a dataframe. I think more generically we could provide the option to register a metadata function (possibly even more than one) for a dataset.
cf_register_meta<-function(dataset, FUN, add = TRUE, after = TRUE) {
}
using cf_register_meta would allow the actual method of storing the metadata FUN to evolve as we change coconatfly. Furthermore it would be a step on the way to actually using the coconat::register_dataset function (which could perhaps use this under the hood?).
Questions/todos
[ ] how do we handle registering of duplicate functions?
[ ] What does add=FALSE mean (does it completely replace the built-in function)?
[ ] What does after mean (does it take priority over the functions that precede it (probably, yes)?
[ ] Do we allow both dataframe or file input?
[ ] Who handles updates for CAVE type data? Probably coconatfly since this is quite generic, but then we should provide a supervoxel_id column to signal this.
[ ] coconatfly would also need to figure out how to do this update for the specified dataset.
The PR for additional fanc_meta (https://github.com/natverse/coconatfly/pull/22) gives one pattern, where we just return accept a path to a file on disk (tsv/feather) or a dataframe. I think more generically we could provide the option to register a metadata function (possibly even more than one) for a dataset.
Where FUN would look like
using
cf_register_meta
would allow the actual method of storing the metadataFUN
to evolve as we change coconatfly. Furthermore it would be a step on the way to actually using thecoconat::register_dataset
function (which could perhaps use this under the hood?).Questions/todos
coconatfly
since this is quite generic, but then we should provide a supervoxel_id column to signal this.