Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#58 "default" options override explicit attribute set

closed-works-for-me
nobody
General (125)
5
2006-02-09
2005-02-26
Jamie Wilkinson
No

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"

Discussion

  • Oleg Broytman
    Oleg Broytman
    2005-03-01

    Logged In: YES
    user_id=4799

    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
     
    • status: closed-invalid --> open-invalid
     
    • assigned_to: nobody --> phd
    • status: open-invalid --> open-accepted
     
  • default attribute test

     
    Attachments
  • Logged In: YES
    user_id=440958

    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
    user_id=4799

    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="")
    t.location="some/path"

    Now your program works.

     
  • Oleg Broytman
    Oleg Broytman
    2005-08-10

    • assigned_to: phd --> nobody
    • status: open-accepted --> open
     
  • Logged In: YES
    user_id=1367914

    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:
    self._SO_createValues.update(kw)
    ... 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
    placing
    self._SO_createValues[name] = dbValue; in the "plainSetter"
    block.

    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
    user_id=4799

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