#58 "default" options override explicit attribute set

General (125)

I traced this behaviour to the patch at revision 425 in
the repository; at rev 422 it works, and at 425 it doesn't.

My object gets its 'location' attribute set, and the
function _set_location reads the file at that location
and sets a few other attributes within that function.

The behaviour I'm seeing is that these attributes are
being set during the function, but when the object is
referenced later, the default value (as specified when
the column is defined) is returned.

There's a short example attached, that's slightly
contrived to demonstrate the structure of the object,
but runs here. The output of such a program at rev 425
is None and at 422 is "a string"


  • Oleg Broytman

    Oleg Broytman - 2005-03-01

    Logged In: YES

    Please reattach the test. And don't forget to mark the
    "Check to Upload and Attach a File" checkbox! (-:

  • Oleg Broytman

    Oleg Broytman - 2005-06-17
    • status: open --> closed-invalid
  • Anonymous - 2005-06-22
    • status: closed-invalid --> open-invalid
  • Anonymous - 2005-06-22
    • assigned_to: nobody --> phd
    • status: open-invalid --> open-accepted
  • Anonymous - 2005-06-22

    default attribute test

  • Anonymous - 2005-06-22

    Logged In: YES

    Ok, I hunted down my test code and I've reattached it, and
    this time I'm sure I've attached it properly :-)

    I've modified it a bit too, it'll print out the result of
    the test.

    I called it like so:

    PYTHONPATH=.:SQLObject python test.py

    with a fresh svn checkout, and again with a checkout at
    revision 421.

  • Oleg Broytman

    Oleg Broytman - 2005-08-10

    Logged In: YES

    You've touched a known problem with setters. Avoid setting
    setters' values in constructor. Instead update them after
    the objecthas ben created:

    t = test(location="")

    Now your program works.

  • Oleg Broytman

    Oleg Broytman - 2005-08-10
    • assigned_to: phd --> nobody
    • status: open-accepted --> open
  • Cody Casterline

    Cody Casterline - 2005-10-25

    Logged In: YES

    I've confirmed this bug, and it looks to be caused by the
    order of operations in SQLObject.set(self, **kw).

    _create() passes default values to set() in **kw.

    set() sets "plainSetter" columns.
    set() sets "extra" (_set_*) columns.
    THEN set() does:
    ... overwriting all of the calculated values just set in the
    "extra" columns block.

    I fixed this on my end by removing the dict.update(), and
    self._SO_createValues[name] = dbValue; in the "plainSetter"

    I haven't submitted it as patch because I'm not sure if this
    breaks anything else. Maybe someone more familiar with the
    code will know. :)

  • Oleg Broytman

    Oleg Broytman - 2006-02-09
    • status: open --> closed-works-for-me
  • Oleg Broytman

    Oleg Broytman - 2006-02-09

    Logged In: YES

    The test.py works now with SQLObject 0.7 so I consider the
    bug resolved even without the patch 1338764.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks