Skip to content

Commit 1add677

Browse files
committed
Remove duplicated preprocessed x,y key check in epix_merge
1 parent 0daf2b1 commit 1add677

File tree

1 file changed

+12
-10
lines changed

1 file changed

+12
-10
lines changed

R/methods-epi_archive.R

Lines changed: 12 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -219,17 +219,15 @@ epix_merge = function(x, y,
219219
y_DT = y$DT[y[["DT"]][["version"]] <= new_versions_end, names(y$DT), with=FALSE]
220220
} else Abort("unimplemented")
221221

222-
if (!identical(key(x$DT), key(x_DT)) || !identical(key(y$DT), key(y_DT))) {
223-
Abort("preprocessing of data tables in merge changed the key unexpectedly",
224-
internal=TRUE)
225-
}
226222
# key(x_DT) should be the same as key(x$DT) and key(y_DT) should be the same
227-
# as key(y$DT). If we want to break this function into parts it makes sense
228-
# to use {x,y}_DT below, but this makes the error checks and messages look a
229-
# little weird and rely on the key-matching assumption above.
223+
# as key(y$DT). Below, we only use {x,y}_DT in the code (making it easier to
224+
# split the code into separate functions if we wish), but still refer to
225+
# {x,y}$DT in the error messages (further relying on this assumption).
230226
#
231-
# Just go ahead and test the above assumption in case different versions of
232-
# data.table or certain inputs cause different behavior:
227+
# Check&ensure that the above assumption; if it didn't already hold, we likely
228+
# have a bug in the preprocessing, a weird/invalid archive as input, and/or a
229+
# data.table version with different semantics (which may break other parts of
230+
# our code).
233231
x_DT_key_as_expected = identical(key(x$DT), key(x_DT))
234232
y_DT_key_as_expected = identical(key(y$DT), key(y_DT))
235233
if (!x_DT_key_as_expected || !y_DT_key_as_expected) {
@@ -242,7 +240,11 @@ epix_merge = function(x, y,
242240
setkeyv(x_DT, key(x$DT))
243241
setkeyv(y_DT, key(y$DT))
244242
}
245-
243+
# Without some sort of annotations of what various columns represent, we can't
244+
# do something that makes sense when merging archives with mismatched keys.
245+
# E.g., even if we assume extra keys represent demographic breakdowns, a
246+
# sensible default treatment of count-type and rate-type value columns would
247+
# differ.
246248
if (!identical(sort(key(x_DT)), sort(key(y_DT)))) {
247249
Abort("
248250
The archives must have the same set of key column names; if the

0 commit comments

Comments
 (0)