@@ -52,13 +52,6 @@ validate_version_bound <- function(version_bound, x, na_ok = FALSE,
52
52
class = " epiprocess__version_bound_mismatched_class"
53
53
)
54
54
}
55
- if (! identical(typeof(version_bound ), typeof(x [[" version" ]]))) {
56
- cli_abort(
57
- " {version_bound_arg} must have the same `typeof` as x$version,
58
- which has a `typeof` of {typeof(x$version)}" ,
59
- class = " epiprocess__version_bound_mismatched_typeof"
60
- )
61
- }
62
55
}
63
56
64
57
return (invisible (NULL ))
@@ -207,23 +200,23 @@ next_after.Date <- function(x) x + 1L
207
200
# ' undergo tiny nonmeaningful revisions and the archive object with the
208
201
# ' default setting is too large.
209
202
# ' @param clobberable_versions_start Optional; `length`-1; either a value of the
210
- # ' same `class` and `typeof` as `x$version`, or an `NA` of any `class` and
211
- # ' `typeof`: specifically, either (a) the earliest version that could be
212
- # ' subject to "clobbering" (being overwritten with different update data, but
213
- # ' using the *same* version tag as the old update data), or (b) `NA`, to
214
- # ' indicate that no versions are clobberable. There are a variety of reasons
215
- # ' why versions could be clobberable under routine circumstances, such as (a)
216
- # ' today's version of one/all of the columns being published after initially
217
- # ' being filled with `NA` or LOCF, (b) a buggy version of today's data being
218
- # ' published but then fixed and republished later in the day, or (c) data
219
- # ' pipeline delays (e.g., publisher uploading, periodic scraping, database
220
- # ' syncing, periodic fetching, etc.) that make events (a) or (b) reflected
221
- # ' later in the day (or even on a different day) than expected; potential
222
- # ' causes vary between different data pipelines. The default value is `NA`,
223
- # ' which doesn't consider any versions to be clobberable. Another setting that
224
- # ' may be appropriate for some pipelines is `max_version_with_row_in(x)`.
225
- # ' @param versions_end Optional; length-1, same `class` and `typeof` as
226
- # ' `x$version`: what is the last version we have observed? The default is
203
+ # ' same `class` as `x$version`, or an `NA` of any `class`: specifically,
204
+ # ' either (a) the earliest version that could be subject to "clobbering"
205
+ # ' (being overwritten with different update data, but using the *same* version
206
+ # ' tag as the old update data), or (b) `NA`, to indicate that no versions are
207
+ # ' clobberable. There are a variety of reasons why versions could be
208
+ # ' clobberable under routine circumstances, such as (a) today's version of
209
+ # ' one/all of the columns being published after initially being filled with
210
+ # ' `NA` or LOCF, (b) a buggy version of today's data being published but then
211
+ # ' fixed and republished later in the day, or (c) data pipeline delays (e.g.,
212
+ # ' publisher uploading, periodic scraping, database syncing, periodic
213
+ # ' fetching, etc.) that make events (a) or (b) reflected later in the day (or
214
+ # ' even on a different day) than expected; potential causes vary between
215
+ # ' different data pipelines. The default value is `NA`, which doesn't consider
216
+ # ' any versions to be clobberable. Another setting that may be appropriate for
217
+ # ' some pipelines is `max_version_with_row_in(x)`.
218
+ # ' @param versions_end Optional; length-1, same `class` as `x$version`: what is
219
+ # ' the last version we have observed? The default is
227
220
# ' `max_version_with_row_in(x)`, but values greater than this could also be
228
221
# ' valid, and would indicate that we observed additional versions of the data
229
222
# ' beyond `max(x$version)`, but they all contained empty updates. (The default
0 commit comments