executesql returns you raw data from the table, without applying a "smart parsing" that usually is accomplished by a normal select().
That being said, it's possible that you just need to issue a query that has a weird condition that you can't replicate using standard DAL syntax. E.g. select table.field1, table.field2 from table where #ultracomplicated condition here In this case you may want to have the same features with the returned resultset (references, 'T' or 'F' to actual boolean values, datetime parsing if needed, etc etc etc) as you would have done doing db(ultracomplicatedquery).select(db.table.field1, db.table.field2) So. fields= stands for whatever you'd need to use in a normal select(). This complies with having fields = [db.table.field1, db.table.field2] or fields = db.table in this case all fields of the table will be used or again fields = [db.table1.field1, db.table2.field2] NB: both field and colnames HAVE to be used in the same order as the columns returned by your executesql statements... it basically does a "what if this executesql would have to parse back the results as they where done by a select() ?" colnames on the other hand are a niftier trick. you can pass a list of strings (hence, ['table.field1', 'table.field2'] not "real" instances of table fields. Until here, they're "interchangeable". However, if you specify both, you can do something else..... consider thesum = db.table1.field1.sum() rows = db(aquery).select(thesum, anotherfield) for row in rows: print row[thesum] if you use an executesql statement, you can do fields=[db.table1.field1.sum()], colnames=['table1.put_the_sum_here'] so basically, when both are specified the fields is used to get the correct type (i.e. for a sum() it will be parsed back as an integer) and you can access it at put_the_sum_here instead of the serialized destination that is set by default in select()s. without fields and colnames the "extraction" of the field names in the resultset wouldn't be as straightforward as it is with a select(). Having both gives you flexibility. As for dummy tables, you may need them to avoid defining a table just for parsing back correctly your executesql()ed query. -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
