On Feb 6, 1:20 pm, "S.R. Larmes" <[EMAIL PROTECTED]> wrote: > > a) How do I do: > > UPDATE sometable SET value = value * 0.9 + 1 [ + optional WHERE > clause ] ? > > I've tried experimenting with .update(values=..) or stuff > like .execute(value=sometable.c.value*0.9+1) but it just tries to do > strange things. (SET value=sometable.value * %(sometable_value)s + % > (literal)s ??)
that looks correct to me...all literal values are by default converted to bind params. if you execute the statement the bind values will be set up correctly. > > b) I have an array (or tuple) with values that I'd just like to fire > off to insert() which is compiled to work on one column (the other > columns have defaults or pre-set values)... To me, this one ought to > be obvious and intuitive, and maybe I'm just stupid or blind, but I > can't find a way. how did you compile an insert() to work on just one (unnamed) column ? like table.insert(values=['someval']) ? > > (Alternatively, if I have an array such as [(1, 'hi', 'text'), (2, > 'hello', 'tuxt'), ...] where the columns match up to the columns in > the table (or a given insert())...) > > .execute(*[dict(name=x) for x in array]) # to me, this is inelegant > and horribly roundabout well, SA is mostly name oriented at this time for several reasons: 1. there is no chance of ambiguity. for example, if you write code that just says table.insert().execute(1,2,3,4,5), supposing the table is reflected from the local database - that code might not be portable if executed on a different database where the table was created with a different column ordering, or had columns added via ALTER, etc. 2. it is more database-neutral to build off named parameters, since its easy to convert from named param to positional, hard to convert in the other direction (ordering may not be consistent depending on how a dialect compiles a statement). as not all DBAPIs support positional bind parameters anyway, SA is going to create named bind parameters in any case so the "inelegant and roundabout" behavior will still occur, albeit behind the scenes, if support for positional execute() arguments were improved. since its *only* inserts that positional parameters even have a chance of working on all DBs, SA's parameter-processing logic was written around a "named parameter" concept since positional params are of very limited use. 3. lets look at the proposed feature itself. let me preface by saying, i will accept this feature into SA, and i am not opposed to it. if an adequate patch is provided, i will commit it. however, its not a priority for me to implement this myself. this is because it would be complex to implement, and the current insert() method is one step and is a "single way to do it". the method you are proposing requries two steps in most cases: i.e. table.insert().execute(*[dict(name=x) for x in array]) specifies the column names and their values in one step. the proposed method requires in most cases a separate column specification step, currently the inelegant: table.insert(values=['fake value 1', 'fake value2']).execute(*array) but if we added a column list argument, would look like: insert([table.c.col1, table.c.col2]).execute(*array) which is still two steps. of course if you want to insert the whole row, then youd leave the table out...then you have some implicit behavior going on which may be less than ideal. also, we now have to check for error conditions like this: insert([table.c.col1, table.c.col2]).execute(col1=5, col2=7, col3=15) this probably breaks right now if you use the values clause in this manner. so..yeah...not against it as a feature, but to me its decidedly more complex and ambiguous than the current method. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
