I think we need a way to serialise Spectra objects. This is trivial for in memory backends - the usual save() and load() apply - but not so for on disk backends.
The the MsBackendMzR, the object could be serialised and once loaded, the validObject() method could be used to check of the original file are still present/available. Same applied to the MsBackendHdf5Peaks.
It isn't that easy for the MsBackendSqlDb given that the connection to the database (SQLite in the current implementation) can't be serialised. It might be possible to store the necessary information to regenerate that connection though, which could be streamlined with a simple function.
But this starts to indicate that we might have to handle backends on a case by case basis. So instead of using the generic save()/load() (or equivalent RDS variants), I suggest that we have a dedicated method that will delegate the backend specificity to the object's backend. For example
setMethod("saveSpectra",
function(object, file, ...) {
## any backend specific preparation
saveRDS(object, file = file, ...)
})
This issue was briefly mentioned in #124.
I think we need a way to serialise
Spectra
objects. This is trivial for in memory backends - the usualsave()
andload()
apply - but not so for on disk backends.MsBackendMzR
, the object could be serialised and once loaded, thevalidObject()
method could be used to check of the original file are still present/available. Same applied to theMsBackendHdf5Peaks
.MsBackendSqlDb
given that the connection to the database (SQLite in the current implementation) can't be serialised. It might be possible to store the necessary information to regenerate that connection though, which could be streamlined with a simple function.But this starts to indicate that we might have to handle backends on a case by case basis. So instead of using the generic
save()
/load()
(or equivalent RDS variants), I suggest that we have a dedicated method that will delegate the backend specificity to the object's backend. For exampleand