Having used the BackupRepository for other things than backups in the ZERO branch, I suspect there might be two separate concerns that are mixed into the same class/abstraction. One is verifying the data to be persisted is not corrupted (this heavily depends on the type of data being persisted obviously), and the other one is doing the actual persisting work. It makes sense to verify the checksum before taking a backup, but IMO this doesn't belong in an implementation dealing with S3 or GCS.
Would separating the Backup part of the BackupRepository abstraction from the Repository part solve the problems you're facing Bruno? Ilan On Tue, Jan 30, 2024 at 9:12 PM David Smiley <dsmi...@apache.org> wrote: > I could imagine making it toggle-able if it serves the index > encryption feature. Dunno if that's easy, hard, or impossible. > > On Tue, Jan 30, 2024 at 10:31 AM Jason Gerlowski <gerlowsk...@gmail.com> > wrote: > > > > > Isn't the intent to ensure we don't waste time/space creating a > > > useless backup of something that is, I suppose, already corrupted? > > > > Space is one benefit, yep. > > > > The other reason is to avoid giving users a false sense of security. A > > user would be very frustrated to find out at restore-time that the > failsafe > > backup they've been relying on is useless. Better to surface that > > information at backup time when the source collection is healthy and the > > backup can be retried, etc. > > > > > > On Tue, Jan 30, 2024 at 10:18 AM Bruno Roustant < > bruno.roust...@gmail.com> > > wrote: > > > > > > Isn't the intent to ensure we don't waste time/space creating a > > > useless backup of something that is, I suppose, already corrupted? > > > > > > That's right. And I didn't read the code enough; a clear effort has > been > > > put here since the last time I read the code, to make all > implementations > > > consistent to verify the checksum. > > > > > > Hum, this is annoying for directory-based encryption. The only way > becomes > > > to have an encryption extension for each and all different > implementations. > > > Less clean than a FilterBackupRepository. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
