From greg_stein@eshop.com Thu May 9 00:25:27 1996 From: greg_stein@eshop.com (Greg Stein) Date: Wed, 8 May 1996 15:25:27 -0800 Subject: [PYTHON DB-SIG] DatabaseAPI.html Message-ID: Hello all! I uploaded an API document a month ago and forgot to send mail :-( You can find the document at: http://www.python.org/sigs/db-sig/DatabaseAPI.html Please review and comment. We'll add a public link to it in a couple weeks. Thanx, -Greg ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From nuucp@cbgw3.att.com Thu May 9 11:36:00 1996 From: nuucp@cbgw3.att.com (nuucp@cbgw3.att.com) Date: Thu, 9 May 96 06:36 EDT Subject: No subject Message-ID: <199605091041.GAA01787@python.org> ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From greg_stein@eshop.com Wed May 15 03:50:57 1996 From: greg_stein@eshop.com (Greg Stein) Date: Tue, 14 May 1996 18:50:57 -0800 Subject: [PYTHON DB-SIG] Re: Python Database API Message-ID: At 11:26 AM 5/15/96, David Morley wrote: >Hi! > >I was reading the Python Database API document and I couldn't figure out >how this would apply to mSQL. In particular, how do you send a query to >the database and get back the rows? It all seems far more complex than >the ``old-interface mSQL'': > >db.query('select * from mytable') > >David Queries are run in two steps: execute() then a fetchXXX method. For example: db = msqldb.msqldb('mydatabase') db.execute('select * from mytable') rows = db.fetchall() The 'rows' would be a list of tuples containing the contents of the rows. The introduction of the "cursor" concept is primarily for performance purposes and would only be available for databases that use them. Since mSQL doesn't have them, your don't have to worry about them at all -- the "cursor methods" would be run directly on the database connection object. The reason for splitting up the execute/fetch is simply that many SQL statements don't return values (INSERT, UPDATE, DELETE, etc), so they would only need an execute(). Also, you could do something like: db.execute('select * from mytable') print db.description That would print out a description of the results before their actual fetch. The split is also useful for enabling some types of performance enhancements. I hope this clears up how the interface might work. I started on a compatibility module that works with the mSQL module, but presents the new interface. It is a bit out of date, though. I have another module that works for the Postgres95 database (using the PyGres module). One day, I might write new C modules for better functionality, but they work well enough now. Feel free to ask away if you have more questions/comments! Regards, Greg Stein, eShop Inc. greg_stein@eshop.com ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From greg_stein@eshop.com Wed May 15 03:50:57 1996 From: greg_stein@eshop.com (Greg Stein) Date: Tue, 14 May 1996 18:50:57 -0800 Subject: [PYTHON DB-SIG] Re: Python Database API Message-ID: At 11:26 AM 5/15/96, David Morley wrote: >Hi! > >I was reading the Python Database API document and I couldn't figure out >how this would apply to mSQL. In particular, how do you send a query to >the database and get back the rows? It all seems far more complex than >the ``old-interface mSQL'': > >db.query('select * from mytable') > >David Queries are run in two steps: execute() then a fetchXXX method. For example: db = msqldb.msqldb('mydatabase') db.execute('select * from mytable') rows = db.fetchall() The 'rows' would be a list of tuples containing the contents of the rows. The introduction of the "cursor" concept is primarily for performance purposes and would only be available for databases that use them. Since mSQL doesn't have them, your don't have to worry about them at all -- the "cursor methods" would be run directly on the database connection object. The reason for splitting up the execute/fetch is simply that many SQL statements don't return values (INSERT, UPDATE, DELETE, etc), so they would only need an execute(). Also, you could do something like: db.execute('select * from mytable') print db.description That would print out a description of the results before their actual fetch. The split is also useful for enabling some types of performance enhancements. I hope this clears up how the interface might work. I started on a compatibility module that works with the mSQL module, but presents the new interface. It is a bit out of date, though. I have another module that works for the Postgres95 database (using the PyGres module). One day, I might write new C modules for better functionality, but they work well enough now. Feel free to ask away if you have more questions/comments! Regards, Greg Stein, eShop Inc. greg_stein@eshop.com ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From jeff@ollie.clive.ia.us Wed May 22 22:27:21 1996 From: jeff@ollie.clive.ia.us (Jeffrey C. Ollie) Date: Wed, 22 May 96 16:27:21 -0500 Subject: [PYTHON DB-SIG] Status of the DB SIG? Message-ID: <199605222127.QAA32020@worf.netins.net> Having just joined this SIG I was wondering what the current status of work is. I found nothing more than the listing in the PSA SIG list and the mission statement. -- Jeffrey C. Ollie ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From greg_stein@eshop.com Thu May 23 23:49:32 1996 From: greg_stein@eshop.com (Greg Stein) Date: Thu, 23 May 1996 14:49:32 -0800 Subject: [PYTHON DB-SIG] Status of the DB SIG? Message-ID: At 4:27 PM 5/22/96, Jeffrey C. Ollie wrote: >Having just joined this SIG I was wondering what the current status of >work is. I found nothing more than the listing in the PSA SIG list and >the mission statement. > >-- >Jeffrey C. Ollie Attached below is a note I sent a couple weeks ago. Jim Fulton has said he will provide some feedback, so we'll be looking forward to that. I've also contributed a module for managing result tuples from database queries. Please look in the archives to dig that up (I don't have it handy on this machine). -Greg ----------------------- Date: Wed, 8 May 1996 15:25:27 -0800 To: db-sig@larch.python.org From: Greg Stein Subject: [PYTHON DB-SIG] DatabaseAPI.html Hello all! I uploaded an API document a month ago and forgot to send mail :-( You can find the document at: http://www.python.org/sigs/db-sig/DatabaseAPI.html Please review and comment. We'll add a public link to it in a couple weeks. Thanx, -Greg ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From greg_stein@eshop.com Thu May 23 23:49:32 1996 From: greg_stein@eshop.com (Greg Stein) Date: Thu, 23 May 1996 14:49:32 -0800 Subject: [PYTHON DB-SIG] Status of the DB SIG? Message-ID: At 4:27 PM 5/22/96, Jeffrey C. Ollie wrote: >Having just joined this SIG I was wondering what the current status of >work is. I found nothing more than the listing in the PSA SIG list and >the mission statement. > >-- >Jeffrey C. Ollie Attached below is a note I sent a couple weeks ago. Jim Fulton has said he will provide some feedback, so we'll be looking forward to that. I've also contributed a module for managing result tuples from database queries. Please look in the archives to dig that up (I don't have it handy on this machine). -Greg ----------------------- Date: Wed, 8 May 1996 15:25:27 -0800 To: db-sig@larch.python.org From: Greg Stein Subject: [PYTHON DB-SIG] DatabaseAPI.html Hello all! I uploaded an API document a month ago and forgot to send mail :-( You can find the document at: http://www.python.org/sigs/db-sig/DatabaseAPI.html Please review and comment. We'll add a public link to it in a couple weeks. Thanx, -Greg ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From greg_stein@eshop.com Wed May 29 22:04:08 1996 From: greg_stein@eshop.com (Greg Stein) Date: Wed, 29 May 1996 13:04:08 -0800 Subject: [PYTHON DB-SIG] Re: db-sig presentation at IPC-IV Message-ID: >... >Great, I look forward to hearing it. Will your presentation include a >discussion of future plans for the API? The current API is a really >good start at standardization, but it seems that something is still >needed to mask SQL from the Python end user. I'm not sure that I'll present the API itself, other than a reference to the page, which I believe is a pretty good presentation in itself. I certainly haven't heard any feedback to debunk my belief :-) Regarding the API: it is impossible to mask SQL from the user. You lose all of the relational capabilities that the database exists for. The intent of the API (from where I'm coming from, which I should write to the sig now that I think about it): "The API is for presenting a database's complete functionality to Python at the most minimal level (Guido's "cover functions for the C library" philosophy). It is not intended to make all databases appear the same, but to create a framework or model that many can use. The intent is for similarity, but not exactitude (which would put too heavy a burden on the module implementor). Due to the wide variety of database capabilities, many of the modules might even expose additional functionality. The benefit arises from having a similar conceptual model and framework between the databases. Since each module exposes its corresponding database's full functionality, it should be possible for a higher-level module to use that functionality to create more abstracted database concepts or to hide differences between actual module implementations." I'll post the above to generate some discussion. The db-sig is too quiet :-) -g ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org =================