#106 begin() lost

MySQLdb-1.1
closed
Andy Dustman
MySQLdb (285)
5
2012-09-19
2004-09-30
Den Ivanov
No

'Connection' object has no attribute 'begin'

Discussion

  • Andy Dustman
    Andy Dustman
    2004-09-30

    Logged In: YES
    user_id=71372

    It's not lost; I took it out. It was a non-standard
    extension, and seems slightly deprecated in favor of using
    START TRANSACTION, which is more standard SQL.

    http://dev.mysql.com/doc/mysql/en/COMMIT.html

    Additionally, there are now (in MySQL-4.1) C API calls for
    commit, rollback, and autocommit, but nothing for begin or
    start transaction.

    You could work around this two ways:

    1) Subclass Connection and add the begin() method back it
    (it only ever did self.query("BEGIN");)

    2) Change your app to do c.execute("BEGIN")

    I'll leave this unresolved for awhile; it wouldn't be a big
    deal to put it back in, but using it in your would adversely
    affect it's portability. I'll also have to see if other
    database modules implement this (like psycopg), in which
    case, it's less of a problem. I'm leaving begin() in the
    1.0.x series.

     
  • Den Ivanov
    Den Ivanov
    2004-09-30

    Logged In: YES
    user_id=852244

    Ok, then remove begin() from documentation.

     
  • Logged In: YES
    user_id=51762

    No offense, but this is super lame. It broke a ton of
    code for me. I'd like to see it re-added and go through
    proper deprecation. An interface change like this should go
    through a rev with a deprecation notice, even if it was
    indeed a nonstandard piece of functionality.

    I'm working around it, but this seems totally hostile.

     
  • Andy Dustman
    Andy Dustman
    2005-03-31

    Logged In: YES
    user_id=71372

    Here's the super lame workaround:

    def begin():
    print "fix your code"

    db.begin = begin

    Auto-commit is on by default, so you don't need begin unless
    you change this for some reason.

    Less lame work-around:

    import MySQLdb
    import MySQLdb.connections

    class MyConnection(MySQLdb.connections.Connection):

    def begin(self):
        from warnings import warn
        warn("fix your code", DeprecationWarning)
        self.query("BEGIN")
    

    MySQLdb.connect = MyConnection

     
  • Logged In: YES
    user_id=51762

    I didn't mean to raise your ire. I'm just giving advice
    while showing my frustration. Had the whole 1.1.x series
    had a docstring in it that said "This is a nonstandard call.
    It is deprecated and will be removed in future versions of
    this library." then I wouldn't have minded. Then it is my
    fault for ignoring a deprecation warning.

    Instead, I find out that I need a recent bugfix, but now
    have to touch up thousands of lines of code to either
    instantiate my wrapper class, run a patched version of the
    module, or convert code to execute begin.

    I'm not saying it was bad thing to remove it. I'm just
    advocating graceful deprecation. The sudden interface
    change is likely to anger/frustrate downstream developers
    who use MySQLdb and have transaction-sensative applications.

    I'd like to see it re-added like this, and left for a few
    versions, thereby warning the entire devloper community of
    the code-breaking change to come:

    def begin():
    """Start a transaction. This is a non-standard
    extension and will be removed in a future version. Use
    cursor.execute("BEGIN") instead."""
    self.query("BEGIN")

     
  • Logged In: YES
    user_id=189789

    Yes, this is pretty weak. It should have been deprecated instead, and
    removed later.

     
  • Andy Dustman
    Andy Dustman
    2005-04-03

    Logged In: YES
    user_id=71372

    This is fixed in CVS in branch-1-2. It won't be going into
    the trunk because that's where 1.3 will be developed. Follow
    the CVS checkout instructions but add -r branch-1-2 to the
    parameters.

    Test this and get back to me. I'll release a beta within the
    next week.

     
  • Logged In: YES
    user_id=51762

    Excellent! My only nit to pick would be that adding the
    "stacklevel=2" extra argument to warn() would be really
    cool. That makes it print the warning, and the line number
    of the calling function instead of this function. It
    basically says "here is where you called the deprecated
    function from". Very handy.

     
  • Andy Dustman
    Andy Dustman
    2005-04-04

    Logged In: YES
    user_id=71372

    OK, I'll do this too.

     
  • Logged In: YES
    user_id=51762

    The current branch-1-2 works well enough for me. The
    stacklevel argument would be neat, but 1.2.1 getting dropped
    would be even cooler.