4 ms·
So the entire argument here is that using sqlite to store files prevents visitors from seeing partial/mid-way changes when updating a website (a process that wo
by superkuh 2y ago
So the entire argument here is that using sqlite to store files prevents visitors from seeing partial/mid-way changes when updating a website (a process that would take seconds)? Is that really a problem?
Otherwise the file system is far superior for every "benefit" they list. And far easier to work with other software and more robust over time (nothing to change/break).
- throwawayie6 2y agoI made something similar once, but simply wrote the output to a temporary file, and then just renamed it to the final name when it was done From what I remember, this was an atomic operation, and if there was a download in progress it would continue using the old file, because the data was still on disk and the filename was simply a pointer to the node. This may behave differently on other file systems. This was done on an old Linux server with ext3 Seems like a simpler solution than using a db
- okl 2y agoOne benefit they list is storing associated metadata in the database (specifically different types of hashes are mentioned) which is not so easy with a file system. I think the bigger benefit though is the increased read performance on many small files (saving system call overhead). To which amount that applies to static files that a smart server might keep in cache, I don't know.
- superkuh 2y agoI'm not sure what associated metadata is in this context but www/path/to/filename.jpg and www/path/to/filename.jpg.json would work and be very file-y. I take their/your point in it not being directly integrated though.