What I like is a system where you first create a plan for what you will do, then there is an executor that will execute the plan. So --dry-run just doesn't run the executor. Of course, depending on what you are working with that might not be possible, but if you can design it like so, do it. It also makes everything nicely decoupled.
Reading from disk, spending CPU cycles, allocating memory, and making queries on the network are all technically side effects--but they're not really cause for "sad panda".
Everything on a computer has some side effects, and the purpose of --dry-run is to stop execution without certain effects that we care about. It's impossible to eliminate side effects entirely, so this is not a goal.
I had http:// 192.168.100.123 :7654/lights_on.sh that idempotentially turns on lights in my room. Trying to query or even pre-fetching does it. I was aware it’s not wisest, wasn’t as stupid as to expose it, also it broke so it is no more, but there’s always the guy who does that.
The "n" key on your keyboard is connected to some dynamite attached under the desk, if you type "--dry-run" or even just "-n", it plays the song "Those Endearing Young Charms" and then explodes, killing everyone in the room.
At some point it doesn't matter if there's "the guy who does that", because the right choice is to let "the guy who does that" deal with the consequences of their own crazy setup.
HTTP GET is also idempotent in REST, and slightly easier than PUT (since you can just append any parameters onto the end of the URL with GET instead of inserting them into the HTTP headers with PUT)
I believe HTTP GET is "nullipotent", meaning that accessing a resource 0 times is supposed to be the same as accessing it once or more. So I don't think it's appropriate for actions like "lights on".
It's impossible to tell if someone is being sarcastic on the internet, because no matter how stupid your comment is at face value, there's always a percentage of people on the forum stupid enough to say it in earnest.
Yeah, not sure how this would work with any workflow that caLLs out to another service and uses the result of that to determine the next step, if that intermediate call changes state somewhere.
Are you worried about that intermediate call changing between the dry run and the actual run? That can be avoided by saving the execution plan and allowing the actual run to load the execution plan from the dry run.
I think a large part of the next 10 years is us figuring out that frameworks are an anti-pattern and that everything is going to have to move to libraries that abide by CQRS.
Did not know what CQRS is, did some light googling[1]:
CQRS (Command and Query Responsibility Segregation) is an alternative to a simple CRUD-based database interface. CQRS separates reads and writes into different models, using commands to update data, and queries to read data.
Commands should be task-based, rather than data centric. ("Book hotel room", not "set ReservationStatus to Reserved").
Commands may be placed on a queue for asynchronous processing, rather than being processed synchronously.
Queries never modify the database. A query returns a DTO that does not encapsulate any domain knowledge.
The models can then be isolated, as shown in the following diagram, although that's not an absolute requirement.
It’s a really practical treatment of CQRS & ES with JS examples. I had heard about CQRS & ES on HN for years but I had never seen any system that actually used it or any practical examples so this book is amazing cause it takes you through how to build a system using them.
Right, but `--dry-run` is just a dry run mode, right? You have to sort of post-process it to create a plan.
I feel like the context for this comment thread was lost. Just to repeat it to forestall any further discussion in this subthread on non-plan dry-run, this is how I saw it:
* Igor: a good way to do dry run is to make plan
* * Me: first time i have seen 'plan' as explicit step for dry-run is with Terraform
* * * fickle: rsync is where i first encounter it [it here is not plan, it is dry-run]
* * * * me: really? rsync has 'plan'?
* * * * * john: rsync has dry-run. read manpage
i.e. Igor and I are talking about explicit plan (which is interesting model) and you guys are talking about dry-run.
Terraform does frequently suffer from the lack of good separation here though, depending on the provider in question - a plan can often succeed where a subseuqent apply will fail. Too much external state / not enough validation, generally.
