FAQ
I'm noticing I'm writing SQL code where I wish to use the Exec(), Query(),
or QueryRow() methods, but there's no interface shared by *sql.Tx and
*sql.DB.

Which means my methods need to decide in advance whether or not a
transaction is necessary for the operation. That seems unnecessary.

Am I missing something, or should I just file an issue that suggests the
collection of the methods:

Exec
Prepare
Query
QueryRow

into a single interface (what to call said interface?). That way, the code
that is manipulating data needn't be aware of whether it is using a
transaction or the convenience functions on *sql.DB?

Eric.


--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Dave Cheney at Jan 3, 2014 at 1:49 am
    You can define this interface in your code if you need it.


    On 3 Jan 2014, at 12:39, Eric Johnson wrote:

    I'm noticing I'm writing SQL code where I wish to use the Exec(), Query(), or QueryRow() methods, but there's no interface shared by *sql.Tx and *sql.DB.

    Which means my methods need to decide in advance whether or not a transaction is necessary for the operation. That seems unnecessary.

    Am I missing something, or should I just file an issue that suggests the collection of the methods:

    Exec
    Prepare
    Query
    QueryRow

    into a single interface (what to call said interface?). That way, the code that is manipulating data needn't be aware of whether it is using a transaction or the convenience functions on *sql.DB?

    Eric.


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Frank Schröder at Jan 3, 2014 at 8:37 am
    For one of my projects I've defined such an interface as a helper and was
    asking myself the same question. I've come to the conclusion that not
    having an interface is better since it makes it clear when a function
    requires transactions and when not. Also, this is helpful when you
    propagate an existing transaction to other (helper-)functions.

    For testing I've used gocheck to start a TX for each test which gets rolled
    back at the end.

    Frank
    On Friday, January 3, 2014 2:39:20 AM UTC+1, Eric Johnson wrote:

    I'm noticing I'm writing SQL code where I wish to use the Exec(), Query(),
    or QueryRow() methods, but there's no interface shared by *sql.Tx and
    *sql.DB.

    Which means my methods need to decide in advance whether or not a
    transaction is necessary for the operation. That seems unnecessary.

    Am I missing something, or should I just file an issue that suggests the
    collection of the methods:

    Exec
    Prepare
    Query
    QueryRow

    into a single interface (what to call said interface?). That way, the code
    that is manipulating data needn't be aware of whether it is using a
    transaction or the convenience functions on *sql.DB?

    Eric.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Toni Cárdenas at Jan 3, 2014 at 11:16 am
    In a project I defined methods on a type SQLStore (CreateUser, DeleteThing,
    CheckWhatever, etc.). SQLStore is a struct with a SQLStoreIO member,
    SQLStoreIO being such common interface. So SQLStore can have inside either
    a transaction or a *sql.DB, and use all the custom methods with both.

    For when, inside a method, I need to make sure I use a transaction, I
    defined a function:

    func ensureTransaction(st *SQLStore) (store SQLStoreIO, commit, rollback
    func() error, err error)

    If st is already a transaction (checked with a type assertion), `commit`
    and `rollback` are no-ops, as the transaction is supposed to be closed
    somewhere else, and the returned `store` is the same object than `st`. If
    not, it starts a new transaction in `store`, `commit` and `rollback` being
    its actual commit and rollback methods.
    On Friday, January 3, 2014 9:37:32 AM UTC+1, Frank Schröder wrote:

    For one of my projects I've defined such an interface as a helper and was
    asking myself the same question. I've come to the conclusion that not
    having an interface is better since it makes it clear when a function
    requires transactions and when not. Also, this is helpful when you
    propagate an existing transaction to other (helper-)functions.

    For testing I've used gocheck to start a TX for each test which gets
    rolled back at the end.

    Frank
    On Friday, January 3, 2014 2:39:20 AM UTC+1, Eric Johnson wrote:

    I'm noticing I'm writing SQL code where I wish to use the Exec(),
    Query(), or QueryRow() methods, but there's no interface shared by *sql.Tx
    and *sql.DB.

    Which means my methods need to decide in advance whether or not a
    transaction is necessary for the operation. That seems unnecessary.

    Am I missing something, or should I just file an issue that suggests the
    collection of the methods:

    Exec
    Prepare
    Query
    QueryRow

    into a single interface (what to call said interface?). That way, the
    code that is manipulating data needn't be aware of whether it is using a
    transaction or the convenience functions on *sql.DB?

    Eric.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 3, '14 at 1:39a
activeJan 3, '14 at 11:16a
posts4
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase