@sckott Unfortunately no. The package workflow is:
data to disk (~TB) -> C++ -> SQLite -> R -> cleanup disk -> out
C++ sqlite bindings and not
RSQLite) and the only way to test anything at all is
test_data -> disk -> C++ -> SQLite -> R -> (do not) cleanup disk -> out
Without the database connection there can be no tests, and having no tests or examples whatsoever actually running on cran can surely not be good practice. Travis is no probs at all. Issues only appear to arise in through the
win-builder machines appearing not to allow the cleanup stage. (I also can not get appveyor to find the
C++ sqlite3 bindings, even though
win-builder and any other windows/docker configs I can find have no probs there, but that's a slightly separate issue.)
The issue about storage location and cleanup policies is, i'd suggest, sufficiently general as to warrant consideration in terms of some kind of general statement about best practice. As soon as i have a satisfactory solution, i'd be keen to contribute in that regard to save others the pain of prolonged searching in vain for a workable solution.
General best practice questions for which answers are likely to be useful:
1. At which stage of tests to establish the db? Just once at the start, and use same throughout, or establish anew for each new block of tests? Likely some kind of first option desirable and can best work so ... but if not, then second option best handled so ...
2. How best to clean up the db at end of (block of) tests?
3. Where to store the db?
Answering these questions is going to require consideration of differences between CRAN, travis, appveyor, and whatever else. The easy bit there is that answers should be generally database independent, so general approaches ought to be possible.