Closed hsyed closed 7 years ago
Just starting out with go. Tests should pass now.
I couldn't find proof on how to use the Conn.TxStatus
to detect status. I bet I will need to detect transaction status eventually in this way.
I'll squash the commits now.
I've merged in your PR. I added a test and made a few adjustments to make it more idiomatic Go in b1e821d9364b58004ac9a12893d2c64263ca02a2. In particular, I simplified the MigratorOptions into a single struct.
@jackc Fair enough looks good ! I copied the pattern from type DialOption func(*dialOptions)
from the grpc code -- but I think the single struct is clearer.
I think this is a reasonable idea, but there are a few implementation details that need to be worked out.
First, the tests are failing (at least on Go 1.8rc3). [1]
Second, I think the API could be improved.
NewMigratorNoTx
works when there is only one optional behavior forMigrator
, but if we were to add another option then we need to add two more functionsNewMigratorOtherOption
andNewMigratorNoTxOtherOption
. I think aNewMigratorEx(conn *pgx.Conn, versionTable string, options *MigratorOptions)
would be a better API. Then any other future options could simple be added toMigratorOptions
and the API would remain unchanged. ForMigratorOptions
we would want the zero value to be default behaviour of internal transactions, so perhaps the option could be calledDisableTx
.On a broader note, to answer your question in #4, Conn.TxStatus could be used to detect if a transaction is in-progress. But I think I prefer the explicit direction you've gone here. OTOH, maybe it would be cool to detect an in-progress transaction and use savepoints to to atomically migrate versions while leaving the overall Tx commit up to the external code. Might be too clever and overcomplicate things though.
[1]