You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
kenmawer
changed the title
as_epi_archive doesn't absorb keys from a keyed data.table or epi_dfas_epi_archive doesn't preserve keys from a keyed data.table or epi_dfAug 12, 2022
keyed data.table + no other_keys arg --> we ignore the current key & replace with default geo time version
epi_df with other_keys + no other_keys arg --> same deal
epi_df with additional metadata --> no $additional_metadata
(Some of these may currently be tested for, but unwanted. We should alter+add tests accordingly.)
We should probably aim for something like the following:
If user provides other_keys arg, just use that as the archive's other keys.
If user does not provide other_keys arg:
If x is an epi_df, set archive other keys as something like c(setdiff(attr(x,"metadata")$other_keys, "version"), "version")
If x is a keyed data.table, check that they key includes geo&time value (error if not), then set archive other keys to c(setdiff(key(x), c("geo_value","time_value","version")), "version")
If x is an unkeyed data.table, use character(0L) as the archive other keys
What should be discussed is to what extent
as_epi_archive
should retain already defined keys in a keyeddata.table
orepi_df
.The text was updated successfully, but these errors were encountered: