You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem: In SQLite, there are three transaction behaviors to choose from when starting a transaction - deferred, immediate, or exclusive. However, there is no way to say which one to use via the existing Begin or BeginTx methods in the database/sql package. And since this is a SQLite-only concept, it would seem strange to make "transaction behavior" a field of the sql.TxOptions struct.
I propose adding a new field for driver-specific transaction options to sql.TxOptions (and driver.TxOptions).
From a compatibility standpoint, one potential issue is that existing drivers that already implement driver.ConnBeginTx would not know to evaluate this new DriverOptions field, so they would allow through potentially invalid input. Then, when that driver gets updated to actually evaluate the new field, it would start returning an error, breaking existing programs. However, it would seem silly for someone to use a driver options struct that isn't supported by their driver package, so this may be an unlikely issue in practice. At worst, yet another optional interface could be added to the database/sql/driver package.
The text was updated successfully, but these errors were encountered:
Problem: In SQLite, there are three transaction behaviors to choose from when starting a transaction - deferred, immediate, or exclusive. However, there is no way to say which one to use via the existing
Begin
orBeginTx
methods in the database/sql package. And since this is a SQLite-only concept, it would seem strange to make "transaction behavior" a field of thesql.TxOptions
struct.I propose adding a new field for driver-specific transaction options to
sql.TxOptions
(anddriver.TxOptions
).The user could then supply an options struct from their driver package, as in the following hypothetical example:
From a compatibility standpoint, one potential issue is that existing drivers that already implement
driver.ConnBeginTx
would not know to evaluate this newDriverOptions
field, so they would allow through potentially invalid input. Then, when that driver gets updated to actually evaluate the new field, it would start returning an error, breaking existing programs. However, it would seem silly for someone to use a driver options struct that isn't supported by their driver package, so this may be an unlikely issue in practice. At worst, yet another optional interface could be added to the database/sql/driver package.The text was updated successfully, but these errors were encountered: