-
Notifications
You must be signed in to change notification settings - Fork 48
Implement log redirection interface #36
base: master
Are you sure you want to change the base?
Conversation
By implementing “runMigrationA” and “runMigrationsA”
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All in all, I like these changes a lot more than the previous ones. My comments can be categorized into a few sections
- Nitpicking
- Autoformatter
- Thumbs ups
As a 3rd party, I don't see any obvious blockers on this. Maintainer will have the final say.
|
||
-- | A version of 'runMigrations' which gives you control of where the log | ||
-- messages are sent to. | ||
runMigrationsA |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know I said runMigrationsA
in the previous review, but this could probably have a more descriptive name? I'm terrible at naming things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MasseR Ha, I have the same problem. I couldn’t come up with something good. I could name it as runMigrationsWithCustomLogWriteFn
but I’m hesitating to add this.
scriptsInDirectory dir >>= go | ||
where | ||
go fs = sequenceMigrations (executeMigrationFile <$> fs) | ||
executeMigrationFile f = executeMigration con verbose f =<< BS.readFile (dir ++ "/" ++ f) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like you ran some kind of autoformatter to the source? I don't mind and if were the maintainer I would pass this, but maybe be on the safe side and avoid autoformatters on unfamiliar codebases? Formatting can be a touchy subject for some.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I didn’t use no formatter. All changes are manual. I realized almost all the lines in the code are limited to 80 chars. But only some aren’t. So I split those lines into few.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still hesitant on it. These kinds of extra changes are just extra noise for the reviewer/maintainer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to touch this line anyway.
@@ -51,7 +53,7 @@ ppException a = catch a ehandler | |||
ehandler e = maybe (throw e) (*> exitFailure) | |||
(pSqlError <$> fromException e) | |||
bsToString = T.unpack . T.decodeUtf8 | |||
pSqlError e = mapM_ putStrLn | |||
pSqlError e = mapM_ (hPutStrLn stderr) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a visible change in behavior, I'm hesitant on this. As far as changes go, this is one of the more benign ones, but does change the behavior
postgresql-simple-migration --help | grep foo
postgresql-simple-migration --help | less
postgresql-simple-migration --help 2>&1 | grep foo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- None of the commands you provided as an example are related to this line in an any way
- There’s no such argument
--help
, I added it to Implement abstract interface for log writes #35 but didn’t in this MR, the command will fail - This will print to
stderr
only in case there were some errors while applying migrations
If you refer to the usage of printUsage
:
- If you provide correct
-h
argument it will, as before, print usage info tostdout
thus, if you use the program correctly, it will work as before. - If you provide incorrect arguments the program, as before, will fail and (this changed in this MR) will print usage info to
stderr
as it should. If you rely somewhere on failure scenario caused by using incorrect arguments then you’re doing something wrong and you’re using the program incorrectly. I think you should not pay any attention to copying bugs in order to keep behavior the same unless you build some platform emulation tool (e.g. WineHQ). - Someone may try to use
--help
argument (which doesn’t exist), it’s the most default one for getting usage info. But to whom I’m telling this, you just tried to do so in your example! And in Bash, if you don’t useset -eo pipefail
, the grepping from your example would succeed (before this change) but this is so only because Bash sucks, it sweeps most of the errors under the carpet by default. It is still a bug. But just for this case I thought it was a good idea to add--help
argument alongwith-h
one as a part of the MR (which I did in Implement abstract interface for log writes #35 but you were against it, I still think it is a good idea).
What's the status of this PR? Does anyone need any help? |
@pjones We’re just waiting for maintainer’s feedback. |
If you ask me it’s ready to go. |
@ameingast Let’s ping the maintainer in case he missed or didn’t receive a notification. |
Relates to #34 (satisfies second part).
runMigrationA
andrunMigrationsA
functions with additional argument of typeEither Text Text -> IO ()
whereLeft
is an error message andRight
is an info messagestderr
instead ofstdout
migrate
executable is printed tostderr
instead ofstdout
in case arguments are incorrect and executable exits with error exit codeThis is the second attempt to implement the feature after #35