Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In praise of –dry-run

henrikwarne.com

Post reply on HN
Print view View original

71–80 of 175 posts

Re: In praise of –dry-run

#71

Post by sixtram »

sixtram wrote: post #70

I use a similar strategy for API design. Every API call is wrapped in a large database transaction, and I either roll back or commit the transaction based on dry-run or wet-run flags. This works well as long as you don’t need to touch the file system. I even wrap emails this way—emails are first written to a database queue, and an external process picks them up every few seconds.

To continue, this design has additional benefits:

The code is not littered with dry-run flag checks; the internal code doesn’t even know that a dry run is possible. Everything is rolled back at the end if needed.

All database referential integrity checks run correctly.

Some drawbacks: any audit logging should run in a separate transaction if you want to log dry runs.

Re: In praise of –dry-run

#72

Post by [deleted] »

digiown wrote: post #48
Joker_vD wrote: post #46

Earlier quoted context omitted.

if [ -n "$DRY_RUN" ] ; then alias rm='echo rm' alias cp='echo cp' fi Of course, output redirects will still overwrite the files, since the shell does it and IIRC this behaviour can't be changed.

set -o noclobber

[deleted]

Re: In praise of –dry-run

#73

Post by xavdid »

I like this pattern a lot, but it's important that the code in the dry path is representative. I've been bitten a few too many times by dry code that just runs `print("would have updated ID: 123")`, but not actually running most of the code in the hot path. Then when I run it for real, some of the prep for the write operation has a bug / error, so my dry run didn't actually reveal much to me.

Put another way: your dry code should do everything up until the point that database writes / API calls / etc actually happen. Don't bail too early

Re: In praise of –dry-run

#74

Post by Izkata »

hdjrudni wrote: post #45
IgorPartola wrote: post #36

Earlier quoted context omitted.

I wouldn’t want most things to work this way: $ rm file.bin $ rm —-commit file.bin $ cat foo.txt > bar.txt $ cat foo.txt | tee —-write-for-real bar.txt $ cp balm.mp3 pow.mp3 $ cp —-i-mean-it balm.mp3 pow.mp3 There is a time and a place for it but it should not be the majority of use cases.

Even in those basic examples, it probably would be useful. `cp` to a blank file? No problem. `cp` over an existing file? Yeah, I want to be warned. `rm` a single file? Fine. `rm /`? Maybe block that one.

That last one would error without doing anything anyway because it's not recursive.

Re: In praise of –dry-run

#75

Post by __turbobrew__ »

Twirrim wrote: post #28
mycall wrote: post #14

I like the opposite too, -commit or -execute as it is assumed running it with defaults is immutable as the dry run, simplifying validation complexity and making the go live explicit.

I've biased towards this heavily in the last 8 or so years now. I've yet to have anyone mistakenly modify anything when they need to pass --commit, when I've repeatedly had people repeatedly accidentally modify stuff because they forgot --dry-run.

—dry-run should default to true

Re: In praise of –dry-run

#76

Post by frogulis »

antinomicus wrote: post #12
cake-rusk wrote: post #9

Earlier quoted context omitted.

Design patterns exist to paper over language deficiencies. Use a language which is not deficient.

Like what?

First class functions and iterators are probably examples of what they mean, in terms of language features that obsolete (GoF) design patterns

Re: In praise of –dry-run

#77

Post by marhee »

xavdid wrote: post #73

I like this pattern a lot, but it's important that the code in the dry path is representative. I've been bitten a few too many times by dry code that just runs `print("would have updated ID: 123")`, but not actually running most of the code in the hot path. Then when I run it for real, some of the prep for the write operation has a bug / error, so my dry run didn't actually reveal much to me. Put another way: your dr…

Doesn’t this conflate dry-running with integration testing? ASAIK the purpose of a dry-run is to understand what will happen, not to test what will happen. For the latter we have testing.

Re: In praise of –dry-run

#78

Post by xavdid »

marhee wrote: post #77
xavdid wrote: post #73

I like this pattern a lot, but it's important that the code in the dry path is representative. I've been bitten a few too many times by dry code that just runs `print("would have updated ID: 123")`, but not actually running most of the code in the hot path. Then when I run it for real, some of the prep for the write operation has a bug / error, so my dry run didn't actually reveal much to me. Put another way: your dr…

Doesn’t this conflate dry-running with integration testing? ASAIK the purpose of a dry-run is to understand what will happen, not to test what will happen. For the latter we have testing.

Yes, but it depends on the context.

For little scripts, I'm not writing unit tests- running it is the test. But I want to be able to iterate without side effects, so it's important that the dry mode be as representative as possible for what'll happen when something is run for real.

Re: In praise of –dry-run

#79

Post by xigoi »

analog31 wrote: post #56
throwaway314155 wrote: post #22

Sort of a strange article. You don't see that many people _not_ praising --dry-run (speaking of which, the author should really learn to use long options with a double dash).

I only saw the emdash in the thread link, but I do know that an iPad "wants" to turn a double dash into an emdash automatically. I have no idea how to disable that default.

If you’re using an iPad, the implicit assumption is that Apple knows better than you what you want to do.

Re: In praise of –dry-run

#80

Post by AmbroseBierce »

xavdid wrote: post #78
marhee wrote: post #77

Earlier quoted context omitted.

Doesn’t this conflate dry-running with integration testing? ASAIK the purpose of a dry-run is to understand what will happen, not to test what will happen. For the latter we have testing.

Yes, but it depends on the context. For little scripts, I'm not writing unit tests- running it is the test. But I want to be able to iterate without side effects, so it's important that the dry mode be as representative as possible for what'll happen when something is run for real.

You understand how subjective that is right? Someone might expect that the database doesn't do the last commit step while other people is perfectly happy that the database engine checks that it has enough writing permissions and is running as a user that can start the process without problems.
Post reply on HN