Quote:
Originally Posted by kovidgoyal
@HendelTBD: I'm afraid there is not going to be an option to run the server readonly, this is because the server is now fundamentally read/write in that many core operations it does require write access to the db. As time passes more and more of these operations will be exposed in the main server interface and trying to maintain two different versions of that interface is too difficult.
|
@kovidgoyal I'm confused about the statement re content server that "
many core operations it does require write access to the db". It's clear that you're adding many server operations which CAN perform updates (i.e. R/W access is required) but I don't understand why they MUST? I dimly recall from discussions in years past that your 2.xx code used off-the-shelf functions which required R/W access even when they performed R/O operations which didn't actually write the database.
What I believe @HendelTBD asked for and what I think I would also like is an R/O server - which of course could NOT perform update operations. I completely understand that you don't want to maintain two UIs, but I personally would be 100% fine with write operations simply failing with an error message along the lines of "This library is read-only". If you're worried about users modifying the library but not the database for instance, I think I could make the library tree be R/O for the server at the filesystem level to prevent inadvertent inconsistency.
With all due respect, all the kill/rsync/restart options feel immensely kludgy compared to simply accessing a networked file system R/W in one place and R/O in another....which really isn't exactly 21st century technology.