@@ -52,13 +52,6 @@ validate_version_bound <- function(version_bound, x, na_ok = FALSE,
5252 class = " epiprocess__version_bound_mismatched_class"
5353 )
5454 }
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- }
6255 }
6356
6457 return (invisible (NULL ))
@@ -207,23 +200,23 @@ next_after.Date <- function(x) x + 1L
207200# ' undergo tiny nonmeaningful revisions and the archive object with the
208201# ' default setting is too large.
209202# ' @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
227220# ' `max_version_with_row_in(x)`, but values greater than this could also be
228221# ' valid, and would indicate that we observed additional versions of the data
229222# ' beyond `max(x$version)`, but they all contained empty updates. (The default
0 commit comments