On Mar 3, 2009, at 4:17 PM, Ricardo Aráoz wrote:
> Now AFAIK this is a dabo cursor, but when I do crsr.fetchall() or
> crsr.fetchone() or crsr.fetchmany() empty lists are returned. OTOH
> with
> crsr.getDataSet() I get a dictionary.
Dabo cursors do the fetchall() as part of execute(), and create the
datasets as tuples of dicts, one dict per row. The dbapi fetchone()/
fetchall() are one-time processes, whereas getDataSet() can be called
as often as you like with as many filters/qualifiers that you like. So
when working with Dabo cursors, forget about the fetch*() methods, and
work with the data sets.
> My question is if there is any cursor
> method I have missed that returns the result set in a list like
> fetchall() in python cursors.
Each dbapi if free to implement different classes of cursors. The
default is to return only the values from the tables; some, like
MySQLdb, have a DictCursor class that returns the data in dict format.
My philosophy is that it makes more sense to rely on column names
rather than position to refer to data, so the Dabo cursor
automatically creates a dict per row, even if the dbapi cursor doesn't
support it. Is there a reason why you need positional values instead
of dicts?
> My second question is (if you have the time) how would you have solved
> this with a Bizobj, I'd like to be able to compare both methods (on a
> non trivial query) so as to better be able to choose according to
> circumstances.
It would be almost identical, but with an additional layer of
abstraction to help me focus on the data, rather than the nitty-gritty
of how it was obtained. Ideally, you shouldn't care about fetchone/
fetchall, or dict cursors vs. tuple cursors, or any of that low-level
stuff. You'd create the bizobj with the connection info, set the SQL,
requery, and just use the data.
> Finally I'd like to report that crsr.getDataSet() is not as
> comfortable
> as it might be. Sometimes the key will be only 'Name' (in the example
> above), some other times it will be 'menu.name' (notice in the
> previous
> case 'Name' was cased) but some other times I use menu.name in the
> query
> and the key will be 'Name'. So I haven't found a rule for the naming
> of
> keys and I have to previously test the queries in order to know the
> key
> names and get the data I need into a list.
I'm not exactly clear as to what the confusion is here. When you run
a query, the result returned by the database has some sort of name
identifying each column in the result set: either the actual column
name, or an alias if your query used the 'as' clause, or a DB-
determined name such as 'SUM(mycol)'. The key in the dataset will
always be the value returned by the dbapi for that column.
-- Ed Leafe
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message:
http://leafe.com/archives/byMID/[email protected]
