We just added it a couple days ago. If you get a chance to try it, let us know if there are any problems.
Anthony On Sunday, August 26, 2012 8:55:52 PM UTC-4, Andrew wrote: > > Thanks Anthony, Wasn't aware of that one, and it looks quite useful. > > > On Monday, August 27, 2012 6:29:55 AM UTC+12, Anthony wrote: >> >> Often wondered about this too. You would also have to call them with >>> executesql. >>> So should the dal API support stored procedure , database macro >>> definitions and execution? >>> >>> Would require work in each database adapter, but could we come up with a >>> single interface ? >>> >> Do you mean for creating stored procedures, or calling them? To call >> them, you can use db.executesql(). If you want the returned data to be >> parsed into a DAL Rows object like a regular select() would be, you can now >> specify a "fields" argument to executesql(). Here's the docstring >> explaining its usage: >> >> Added 2012-08-24 "fields" optional argument. If not None, the >> results cursor returned by the DB driver will be converted to a >> DAL Rows object using the db._adapter.parse() method. This requires >> specifying the "fields" argument as a list of DAL Field objects >> that match the fields returned from the DB. The Field objects should >> be part of one or more Table objects defined on the DAL object. >> The "fields" list can include one or more DAL Table objects in addition >> to or instead of including Field objects, or it can be just a single >> table (not in a list). In that case, the Field objects will be >> extracted from the table(s). >> >> The field names will be extracted from the Field objects, or optionally, >> a list of field names can be provided (in tablename.fieldname format) >> via the "colnames" argument. Note, the fields and colnames must be in >> the same order as the fields in the results cursor returned from the DB. >> >> Anthony >> > --
