Re: updateSome() has difficulty with WHERE arguments

On Thu, Aug 18, 2005 at 10:15:29PM -0700, Matthew Bogosian wrote:
> 
> I will be the first to admit that I have no idea what kind of voodoo 
> magic goes on in the updateSome method, but I have noticed a behavior 
> that seems to be erroneous.

Yes, it certainly is (was!).  
> 
> According to the documentation, updateSome can take additional 
> arguments (just like getSome) which refine which rows will receive the 
> updates. However, the values given in the first argument (the dict) 
> seem to be ignored if the subsequent argument is present. 

This only occurred when the additional arguments for the where clause
were of the form <basestring>, <*values>; it worked when PyDO
operators were passed.  The problem was that the worker method for
coming up with the sql and values failed when a converter was passed
to it with pre-existing values (from the update part of the statement)
and also got a sql string; it ignored the converter (which normally it
doesn't use when the sql is already is string form).  I've added code
that attempts to merge the values together.

It will fail if the bind format being used in the sql is not the
format native to the driver; with a ValueError, if it catches the
discrepancy, or a db error, if not.  (It currently isn't that smart
about figuring out what format is being used, and only looks for a
difference in the type of converter.values and the values passed with
the sql string.)

I've added a test, test_updateSome3.  

Thanks for the bug report!

js


> For example, 
> I can do...
> 
> 	MyTable.updateSome({'some_value': 0})
> 
> ...and it works. However, when I do...
> 
> 	My_table.updateSome({'some_value': 0}, 'some_other_value = %s AND 
> some_other_other_value = %s', 1, 2)
> 
> ...I receive an exception:
> 
> 	ProgrammingError: not enough arguments for format string
> 
> I printed out "sqlbuff" and "values" right before the line...
> 
> >		return conn.execute(''.join(sqlbuff), values)
> 
> ...in pydo/base.py in the updateSome() classmethod. I got this...
> 
> >['UPDATE ', 'my_table', ' SET ', 'some_value = %s']
> >[0]
> 
> ...for the first call (without the where clause), and this...
> 
> >['UPDATE ', 'my_table', ' SET ', 'some_value = %s', ' WHERE ', 
> >'some_other_value = %s AND some_other_other_value = %s']
> >(1L, 2L)
> 
> ...for the second call (with the where clause).
> 
> In the second call, it looks like the value in the dict is not 
> reflected in "values". However, since it's not straightforward to me 
> how "values" is constructed in the absence of the WHERE clause, I don't 
> know how to begin debugging this. One curious thing I did note though 
> was that in the first call, values is a list and the value is an 
> integer, whereas in the second, it's a tuple, and the values are both 
> long integers.
> 
> 	-- Matt
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (Darwin)
> 
> iD8DBQFDBWr3nLpDzL5I7l8RAuI/AJ9V9TtwqKbXlujk7alJwrePLJnmJwCfas6F
> ER4mAaEbS6pvvqH8Sn384js=
> =Cx37
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Skunkweb-list mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/skunkweb-list
> 

-- 
Jacob Smullyan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDBcyGuqamFyFXXLIRAlc2AJ4jr02RANOKIJ+1vzoMXCoL1K1BNwCglE01
YUkB57XIhmUWKwNl9AfpUmg=
=5Mql
-----END PGP SIGNATURE-----