4 ms·

If people just randomly delete files they don't fully understand on a production system maybe they should be bitten.

bsaul 3y ago
in the case of sqlite though, the technology is often used as a standalone file format. So it is very tempting to consider the ".sqlite" file to be the one containing all the data, and all the rest to be temporary files that don't matter much. IMHO this (having a variable number of files containing the data, depending on your configuration) is the only real design quirks of this technology.
- another2another 3y ago
  Indeed sqlite's original mission was "to be a replacement for fopen()", but as more features are being added it looks like that initial simplicity can't be maintained.
- resoluteteeth 3y ago
  > in the case of sqlite though, the technology is often used as a standalone file format. So it is very tempting to consider the ".sqlite" file to be the one containing all the data, and all the rest to be temporary files that don't matter much. If you're using it as a standalone file format you presumably shouldn't leave .sqlite files with associated wal files lying around in places where users are going to get confused by them, either by sticking to the rollback journal mode or by using some other method
  - fauigerzigerk 3y ago
    If you use sqlite as a standalone file format for an app that has user managed files then it is hard to avoid this confusion. Rollback journal mode creates a temporary file as well. Also, a scheduled backup process might come along at any moment and non-atomically copy the database file and any -journal or -wal files. Ideally, user visible files should survive copying at random points in time without corruption and without losing too much recent data. Having read "How To Corrupt An SQLite Database File"[1], I'm still not quite sure how to achieve this. [1] https://www.sqlite.org/howtocorrupt.html https://www.sqlite.org/howtocorrupt.html
- worksonmine 3y ago
  The default mode for sqlite isn't WAL though so turning that on is a choice. End-users should have a safe mode of backup if they're not expected to understand the tech. I know reading the manual isn't very common and people are lazy, but getting burned can be a useful and necessary lesson.
paulddraper 3y ago
But in development...
- worksonmine 3y ago
  ...it can be excused because it's expected to be purged regularly and the developer may not even know databases very well.
macintux 3y ago
~25 years ago I rebooted a Solaris server, only to discover that some previous person in my role apparently had, while scrounging around for things to delete to free up disk space on the root partition, removed the kernel file. It happens. (I'm really, really hoping the "previous" person wasn't me.)
IshKebab 3y ago
"If people just randomly don't look at the road and crash then maybe they should die." You make mistakes. Do you want them to be as painful as possible?
- worksonmine 3y ago
  That's hyperbole.

in the case of sqlite though, the technology is often used as a standalone file format. So it is very tempting to consider the ".sqlite" file to be the one containing all the data, and all the rest to be temporary files that don't matter much. IMHO this (having a variable number of files containing the data, depending on your configuration) is the only real design quirks of this technology.

another2another 3y ago
Indeed sqlite's original mission was "to be a replacement for fopen()", but as more features are being added it looks like that initial simplicity can't be maintained.
resoluteteeth 3y ago
> in the case of sqlite though, the technology is often used as a standalone file format. So it is very tempting to consider the ".sqlite" file to be the one containing all the data, and all the rest to be temporary files that don't matter much. If you're using it as a standalone file format you presumably shouldn't leave .sqlite files with associated wal files lying around in places where users are going to get confused by them, either by sticking to the rollback journal mode or by using some other method
- fauigerzigerk 3y ago
  If you use sqlite as a standalone file format for an app that has user managed files then it is hard to avoid this confusion. Rollback journal mode creates a temporary file as well. Also, a scheduled backup process might come along at any moment and non-atomically copy the database file and any -journal or -wal files. Ideally, user visible files should survive copying at random points in time without corruption and without losing too much recent data. Having read "How To Corrupt An SQLite Database File"[1], I'm still not quite sure how to achieve this. [1] https://www.sqlite.org/howtocorrupt.html https://www.sqlite.org/howtocorrupt.html
worksonmine 3y ago
The default mode for sqlite isn't WAL though so turning that on is a choice. End-users should have a safe mode of backup if they're not expected to understand the tech. I know reading the manual isn't very common and people are lazy, but getting burned can be a useful and necessary lesson.

paulddraper 3y ago

But in development...

worksonmine 3y ago
...it can be excused because it's expected to be purged regularly and the developer may not even know databases very well.

macintux 3y ago

~25 years ago I rebooted a Solaris server, only to discover that some previous person in my role apparently had, while scrounging around for things to delete to free up disk space on the root partition, removed the kernel file. It happens. (I'm really, really hoping the "previous" person wasn't me.)

IshKebab 3y ago

"If people just randomly don't look at the road and crash then maybe they should die." You make mistakes. Do you want them to be as painful as possible?

worksonmine 3y ago
That's hyperbole.