[Twisted-Python] About adodb
I'm not too familiar with ADOdb, what are the benefits? Quoting the author: "You might ask why Python needs a database abstraction library when Python provides the official DB API. Unfortunately the DB API does not encapsulate differences in the database implementations. For example, to select a limited number of rows, say 10 rows, you would have to use very different SQL for different databases. [...] These differences are handled by ADOdb (using SelectLimit), but not by
Dave, thanks for your reply. the Python DB API. Other important database differences transparently handled by ADOdb include date-formating, associative arrays (records as dictionaries) and LOB-handling."
By rewrite, do you mean that the new version only uses ADOdb, or have you added ADOdb as a supported back-end? ADOdb adds a level of abstraction on top of db-api. I wrote a version of ConnectionPool that uses adodb connections instead of the regular dbapi connections and cursors. If this is something python developers find useful, i don't know. I guess it isn't as necessary as in php (which i'm switching from) where no common db-api exists, but I still think it's quite a nice thing.
sqlreflector and row could definitely use a reworking. I don't think they are used much. I think people mainly use adbapi and write their own object mapping system. What sort of things did you have in mind? Well mainly validating the data assigned to a rowobject so one can be sure it makes it into the db (checking data length, proper dates etc). But if row and sqlreflector isn't used I'll probably build something new instead of going through that code. I'm thinking of using the db_row module (http://opensource.theopalgroup.com) which seems to offer efficient row data access.
/Simon (STemplar)
On Fri, 2004-10-01 at 04:26, Simon wrote:
Dave, thanks for your reply.
I'm not too familiar with ADOdb, what are the benefits? Quoting the author: "You might ask why Python needs a database abstraction library when Python provides the official DB API. Unfortunately the DB API does not encapsulate differences in the database implementations. For example, to select a limited number of rows, say 10 rows, you would have to use very different SQL for different databases. [...] These differences are handled by ADOdb (using SelectLimit), but not by the Python DB API. Other important database differences transparently handled by ADOdb include date-formating, associative arrays (records as dictionaries) and LOB-handling."
That sound useful. Does the python adodb implementation allow you to use datetime objects transparently?
By rewrite, do you mean that the new version only uses ADOdb, or have you added ADOdb as a supported back-end? ADOdb adds a level of abstraction on top of db-api. I wrote a version of ConnectionPool that uses adodb connections instead of the regular dbapi connections and cursors. If this is something python developers find useful, i don't know. I guess it isn't as necessary as in php (which i'm switching from) where no common db-api exists, but I still think it's quite a nice thing.
So this would implement a super-set of the adbapi interface, then? I think this would probably be a useful addition.
sqlreflector and row could definitely use a reworking. I don't think they are used much. I think people mainly use adbapi and write their own object mapping system. What sort of things did you have in mind? Well mainly validating the data assigned to a rowobject so one can be sure it makes it into the db (checking data length, proper dates etc). But if row and sqlreflector isn't used I'll probably build something new instead of going through that code. I'm thinking of using the db_row module (http://opensource.theopalgroup.com) which seems to offer efficient row data access.
db_row has already been mentioned on this list as a nice module. But wouldn't the associative array aspects of adodb eliminate the need for db_row? dave
db_row has already been mentioned on this list as a nice module. But wouldn't the associative array aspects of adodb eliminate the need for db_row?
Yep, functionwise it would be pretty much the same. db_row however has the advantage of using a different storage mechanism eliminating the need for a dictionary in each object (using __slots__). If you load a lot of objects that should be an advantage. My idea is to subclass db_row to add some data validation routines. Perhaps we could add some foreignkey functionality also to make it a worthy replacement of RowObject. /Simon
On Sat, 2004-10-02 at 02:35, Simon wrote:
db_row has already been mentioned on this list as a nice module. But wouldn't the associative array aspects of adodb eliminate the need for db_row?
Yep, functionwise it would be pretty much the same. db_row however has the advantage of using a different storage mechanism eliminating the need for a dictionary in each object (using __slots__). If you load a lot of objects that should be an advantage. My idea is to subclass db_row to add some data validation routines. Perhaps we could add some foreignkey functionality also to make it a worthy replacement of RowObject.
That sounds like a good plan. An extension to adbapi to return db_row objects would be helpful too. There is a patch to do that now: http://www.twistedmatrix.com/users/roundup.twistd/twisted/issue632 But I think db_row is a better solution. Maybe you could post your code to that bug? thanks, dave
participants (2)
-
Dave Peticolas -
Simon