News for hackers. Stuff that matters.
Re:SQLite the only database you will ever need in most cases by lelandbatey on Wednesday February 15, 2023 @08:09PM (#34813556)
It's a file is relevant. It allows you to think of it like other files:

- how do you back up a JPG? You copy it, cause it's a file

- how do you replicate it? You copy it, cause it's a file. Unless you're talking about fancy DB replication, in which case well, that's not really a thing we do with files much. You'll have to do more research. but that's cause you're trying to do non-file things to a file.

- how do you handle two different processes accessing a JPG? They both open and read the JPG. Same for SQLite. For other concerns, you're trying to do things that don't map well to files, so once again more research needed.

Re:SQLite the only database you will ever need in most cases by billyhoffman on Wednesday February 15, 2023 @08:28PM (#34813724)
Only you can’t copy it if it’s in the middle of a transaction or you corrupt it and have to roll back the Journal. And coping the journal, WAL, and DB itself directly and trying to backup from that isn’t recommended. In fact SQLite itself has a purpose built backup API.

https://www.unixsheikh.com/articles/sqlite-the-only-database...

Yes, technically a SQLite database is just a file on disk. And for the most part, you can treat it like other files on disk. Except for when you can’t. The GP’s questions are valid

Re:SQLite the only database you will ever need in most cases by sanderjd on Wednesday February 15, 2023 @08:22PM (#34813665)
I don't update and append to jpgs though...
Re:SQLite the only database you will ever need in most cases by aembleton on Thursday February 16, 2023 @04:37AM (#34816752)
how do you handle two different processes writing to a JPG?