This reduces the number of file entries we carry in the database,
sometimes significantly. The downside is that if a file is deleted while
a device is offline, and that device comes back more than the cutoff
interval (six months) later, those files will get resurrected at some
point.
The current limit is far too low for our workloads. Perhaps we should
aim even higher than the 64MiB this patch proposes?
Citing the sqlite docs:
> [...] after committing a transaction the rollback journal file may
remain in the file-system. **This increases performance for subsequent
transactions since overwriting an existing file is faster than append to
a file**, but it also consumes file-system space.
tl;dr: if the limit is too low, we're shooting ourselves in the foot in
terms of performance.
Switch the database from LevelDB to SQLite, for greater stability and
simpler code.
Co-authored-by: Tommy van der Vorst <tommy@pixelspark.nl>
Co-authored-by: bt90 <btom1990@googlemail.com>
- Remove full details from ItemStarted (unnecessary, incorrect CamelCase)
- Add "type" ("file" or "dir") to both events
- Add "action" (what we tried to do - "delete" or "update") to both
events.
Integers are for numbers, enabling arithmetic like subtractions and for
loops without getting shot in the foot. Unsigneds are for bitfields.
- "int" for numbers that will always be laughably smaller than four
billion, and where we don't care about the serialization format.
- "int32" for numbers that will always be laughably smaller than four
billion, and will be serialized to four bytes.
- "int64" for numbers that may approach four billion or will be
serialized to eight bytes.
- "uint32" and "uint64" for bitfields, depending on required number of
bits and serialization format. Likewise "uint8" and "uint16", although
rare in this project since they don't exist in XDR.
- "int8", "int16" and plain "uint" are almost never useful.
