has anyone considered doing database helper functions based off of the DB 2.0 api? the question is inspired by the amount of work that is needed to create a useable suite of database queries in the shortest period of time - something that is important when both developing databases and also when doing lots of database applications one after the other. also for some of the background please see the advogato article http://advogato.org/article/600.html particularly the link to jmg's code which contains some very simple to use but obscure coding methods to wrap SQL databases in objects. the reason i ask is because the DB 2.0 api is great in that it makes things easy-ish to add in different databases (e.g. MySQL, MS-SQL, PostgreSQL) if you can deal with the syntactical differences, but it doesn't help you do things like: - make a query that gets you some results - modify one of the results - write the modified results back. i would _expect_ that the cursor class would have a function called save() which performed the last of these operations. e.g. as follows: cur = db.execute("select name from table where id=20") cur[0] = "fred's new name" cur.save() where the save() will AUTOMATICALLY create a database statement: update table set name="fred's new name" where id=20 now, i realise that the above idea has quite a lot of SQL-specific dependence: that can be dealt with by providing base classes where the analysis or creation of the query and also the save() function can be over-ridden. e.g. a class named DBgeneratorBase and therefore an example class can be created e.g. DBgeneratorSQL. i was therefore wondering about two things: - what do people on the python-dev list think of this concept? - is it something appropriate to be included in the python libs, given that the python db API at present is more of a convention than something that is enforced as part of the python library suite. -- ---------------------------------------------------------- this message is private, confidential, and is intented for the specified recipients only. if you received in error, altered, deleted, modified, destroyed or interfered with the contents of this message, in whole or in part, please inform the sender (that's me), immediately. if you, the recipient, reply to this message, and do not then receive a response, please consider your reply to have been lost or deliberately destroyed: i *always* acknowledge personal email received. please therefore take appropriate action and use appropriate protocols to ensure effective communication. thank you.
On Sun, 2 Feb 2003, Luke Kenneth Casson Leighton wrote:
has anyone considered doing database helper functions based off of the DB 2.0 api?
Yes; though the conversation is best had on the DB-SIG mailing list.
the question is inspired by the amount of work that is needed to create a useable suite of database queries in the shortest period of time - something that is important when both developing databases and also when doing lots of database applications one after the other.
I've found that rapid initial development is far less important than ease of validation, maintenance, and portability. My belief is based on writing and maintaining Python applications that interface to, at times >8 heterogeneous database backends, each with many hundreds of tables and distinct OTP and OLAP queries.
also for some of the background please see the advogato article http://advogato.org/article/600.html particularly the link to jmg's code which contains some very simple to use but obscure coding methods to wrap SQL databases in objects.
We (my company) and many others have their own SQL generation and OR mapping implementations that are considerably more advanced. Some (like mine) are in the process of transitioning to an open source development model, while some are already freely available (see http://colorstudy.com/software/SQLObject for one released just last week). So maybe it is time for all of us to get together and put the Open Source "bazaar" to the test and see what comes out.
the reason i ask is because the DB 2.0 api is great in that it makes things easy-ish to add in different databases (e.g. MySQL, MS-SQL, PostgreSQL) if you can deal with the syntactical differences, but it doesn't help you do things like:
- make a query that gets you some results
- modify one of the results
- write the modified results back.
i would _expect_ that the cursor class would have a function called save() which performed the last of these operations.
I would not (for many reasons what I will be happy to elaborate on later). Primarily, DB-API is intended to supply low level access to database connections, transactions, simple result sets, SQL pass-through, and some data type mapping capabilities. The functionality you desire is complex enough that it deserves its own layer/tier that sits on top of DB-API modules.
i was therefore wondering about two things:
- what do people on the python-dev list think of this concept?
The idea is great, though there is a good deal of design that needs to be done. I say this from experience, having built such a system.
- is it something appropriate to be included in the python libs, given that the python db API at present is more of a convention than something that is enforced as part of the python library suite.
Absolutely not. Even after such a scheme has been battle-tested for a few years and has a large and active user base, it will likely be very large and have a radically different development cycle than the core interpreter. However, if you care that much about formal Python legitimacy, then you can work with DB-SIG to write a new standard for the features you desire. Anyhow, we should move the rest of this discussion to the DB-SIG mailing list (db-sig@python.org). Thanks, -Kevin -- -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com
On Sun, 2003-02-02 at 09:51, Kevin Jacobs wrote:
also for some of the background please see the advogato article http://advogato.org/article/600.html particularly the link to jmg's code which contains some very simple to use but obscure coding methods to wrap SQL databases in objects.
We (my company) and many others have their own SQL generation and OR mapping implementations that are considerably more advanced. Some (like mine) are in the process of transitioning to an open source development model, while some are already freely available (see http://colorstudy.com/software/SQLObject for one released just last week). So maybe it is time for all of us to get together and put the Open Source "bazaar" to the test and see what comes out.
There is a list of a number of such interfaces here: http://www.python.org/cgi-bin/moinmoin/HigherLevelDatabaseProgramming If there's any missing I hope someone will extend them. Currently listed are: DbObj db_row ll.sql PgResultSet MiddleKit Object Relational Membrame PyDo SQLBuilder SQLDict SQLObject In various forms these address exactly what Luke was proposing. -- Ian Bicking Colorstudy Web Development ianb@colorstudy.com http://www.colorstudy.com PGP: gpg --keyserver pgp.mit.edu --recv-keys 0x9B9E28B7 4869 N Talman Ave, Chicago, IL 60625 / (773) 275-7241
On Sun, Feb 02, 2003 at 02:30:37PM -0600, Ian Bicking wrote:
On Sun, 2003-02-02 at 09:51, Kevin Jacobs wrote:
also for some of the background please see the advogato article http://advogato.org/article/600.html particularly the link to jmg's code which contains some very simple to use but obscure coding methods to wrap SQL databases in objects.
We (my company) and many others have their own SQL generation and OR mapping implementations that are considerably more advanced. Some (like mine) are in the process of transitioning to an open source development model, while some are already freely available (see http://colorstudy.com/software/SQLObject for one released just last week). So maybe it is time for all of us to get together and put the Open Source "bazaar" to the test and see what comes out.
There is a list of a number of such interfaces here: http://www.python.org/cgi-bin/moinmoin/HigherLevelDatabaseProgramming
If there's any missing I hope someone will extend them. Currently listed are:
DbObj db_row ll.sql PgResultSet MiddleKit Object Relational Membrame PyDo SQLBuilder SQLDict SQLObject
In various forms these address exactly what Luke was proposing.
GREAT! example, the next application is a replacement for an extremely poorly written php app. it contains classes (base class a db class that does the db connection) the classes basically take a unique primary key, do a SELECT, record the row of info in the class instance as variables, then obviously it's possible to modify any of the variables, then there's a save() method. _all_ of this code has been hand-crafted! madness! take the SQL file, auto-generate the darn code, for pity's sake. i've been working some way towards this "ideal" goal. see http://sf.net/projects/pysqldb. more later, have a real-world application / customer to keep happy :) l.
At 12:21 PM 2/3/2003 +0000, Luke Kenneth Casson Leighton wrote:
I feel frustrated when pointed to a package that has no documentation. Is there some? Bob Gailer mailto:ramrom@earthling.net 303 442 2625 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.445 / Virus Database: 250 - Release Date: 1/21/2003
On Sun, Feb 02, 2003 at 10:51:14AM -0500, Kevin Jacobs wrote:
On Sun, 2 Feb 2003, Luke Kenneth Casson Leighton wrote:
has anyone considered doing database helper functions based off of the DB 2.0 api?
Yes; though the conversation is best had on the DB-SIG mailing list.
okay thx! will post there in future.
participants (4)
-
Bob Gailer -
Ian Bicking -
Kevin Jacobs -
Luke Kenneth Casson Leighton