You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@kennethreitz has launched Records, "SQL for Humans™". Given the relative star count (~1,500 in 6 days vs. 36 in 3 years), it seems that the Python world now has a de facto DB-API 3.0—and it's not ours. :o)
Records is database-agnostic (cf. kennethreitz/records#41). So far it seems to me that there's value in continuing with Postgres.py because of the ORM layer. The proposal here is to change our top-level run/one/all API to conform to what @kennethreitz has come up with:
row_iterator=db.query('select * from foo')
row_list=row_iterator.all()
So we'd essentially rename run to query, and chain all (and one, which Records doesn't have—yet?) onto the result.
The text was updated successfully, but these errors were encountered:
@kennethreitz has launched Records, "SQL for Humans™". Given the relative star count (~1,500 in 6 days vs. 36 in 3 years), it seems that the Python world now has a de facto DB-API 3.0—and it's not ours. :o)
Records is database-agnostic (cf. kennethreitz/records#41). So far it seems to me that there's value in continuing with Postgres.py because of the ORM layer. The proposal here is to change our top-level
run
/one
/all
API to conform to what @kennethreitz has come up with:So we'd essentially rename
run
toquery
, and chainall
(andone
, which Records doesn't have—yet?) onto the result.The text was updated successfully, but these errors were encountered: