Thread: C++ client libs
Hi, I was wondering if anyone could offer me some pointers in extending the C++ classes used for client applications? I'm interested in developing a set of C++ classes which will interact directly with the postgres back-end with the following enhancements to the current implementation: These are preliminary musings and definitely open to change. 1) Implement connections as a stream object. e.g. db = new pg_database(char * connection_params); db << sql_string; 2) Implement results as a returned object from pg_database result = db.exec(); result >> field1 >> field2 >> field3; and field = result["field"]; field = result[fieldnum]; 3) Implement asynchronous calls to the back-end permitting multiple queries to be executed concurrently 4) Implement a standard set of exceptions which can be thrown ex. if connection to back-end is interrupted or cannot beestablished within 30 seconds of the first attempt, throw. 5) I'm looking at making the libraries portable between FreeBSD, Solaris Linux and Win32. If anyone has suggestions/additions to this list it would be greatly appreciated! Cheers, Randy Jonasz Software Engineer Click2net Inc. Web: http://www.click2net.com Phone: (905) 271-3550 "You cannot possibly pay a philosopher what he's worth, but try your best" -- Aristotle
On Tue, Oct 03, 2000 at 02:47:45PM -0400, Randy Jonasz wrote: > I was wondering if anyone could offer me some pointers in extending the > C++ classes used for client applications? I'm interested in developing a > set of C++ classes which will interact directly with the postgres back-end > with the following enhancements to the current implementation: > > These are preliminary musings and definitely open to change. > > 1) Implement connections as a stream object. e.g. > db = new pg_database(char * connection_params); > db << sql_string; I don't really like heavy overloading of stream-type things.In this case I think it may make sense, but I preferthe db.Exec(sql_string)system for clarity... > 2) Implement results as a returned object from pg_database > result = db.exec(); > result >> field1 >> field2 >> field3; > and > field = result["field"]; > field = result[fieldnum]; The above system puts some state into the result object. Overloadingarray operators can be sketchy, too.The current systemdefinitely needs to decouple the result from theconnection. I find that the current API causes most implementationstocreate a lot of independent connections to the backend. > 3) Implement asynchronous calls to the back-end permitting multiple > queries to be executed concurrently Yes. I was going to do this in order to make use of the NOTIFY/LISTENfunctionality as well. > 4) Implement a standard set of exceptions which can be thrown > ex. if connection to back-end is interrupted or cannot be established > within 30 seconds of the first attempt, throw. If you really want exceptions, sure. I don't like 'em myself, but Ican understand their advantages. > 5) I'm looking at making the libraries portable between FreeBSD, Solaris > Linux and Win32. Please add BeOS that that list--I'll help keep it in line. > If anyone has suggestions/additions to this list it would be greatly > appreciated! I'm very interested in helping with this (it is on my list of projectsand I've managed to stop adding new ones to the listfor now). Shouldwe take this off-list, or keep it here? In either case, I'll spend some time formally thinking about myperfect API and we can get together and compare notes... -- Adam Haberlach | A billion hours ago, human life appeared on adam@newsnipple.com | earth. A billion minutes ago, Christianity http://www.newsnipple.com | emerged. A billion Coca-Colas ago was '88 EX500 | yesterday morning. -1996 Coca-Cola Ann. Rpt.
Thanks for responding so quickly. Your help would be most welcome. I need to do some further research as well before laying down an API. The company I work for has offered to set up a CVS box open to the public for developing this API. There's another person who has expressed interest in this project as well. What I suggest is working together in developing concrete/virtual classes with each of their member functions laid out on paper first. We can then parcel out the actual coding of the classes between us, using CVS to keep track of our code. Cheers, Randy On Tue, 3 Oct 2000, Adam Haberlach wrote: > On Tue, Oct 03, 2000 at 02:47:45PM -0400, Randy Jonasz wrote: > > > I was wondering if anyone could offer me some pointers in extending the > > C++ classes used for client applications? I'm interested in developing a > > set of C++ classes which will interact directly with the postgres back-end > > with the following enhancements to the current implementation: > > > > These are preliminary musings and definitely open to change. > > > > 1) Implement connections as a stream object. e.g. > > db = new pg_database(char * connection_params); > > db << sql_string; > > I don't really like heavy overloading of stream-type things. > In this case I think it may make sense, but I prefer > the db.Exec(sql_string) system for clarity... > > > 2) Implement results as a returned object from pg_database > > result = db.exec(); > > result >> field1 >> field2 >> field3; > > and > > field = result["field"]; > > field = result[fieldnum]; > > The above system puts some state into the result object. Overloading > array operators can be sketchy, too. > > The current system definitely needs to decouple the result from the > connection. I find that the current API causes most implementations > to create a lot of independent connections to the backend. > > > 3) Implement asynchronous calls to the back-end permitting multiple > > queries to be executed concurrently > > Yes. I was going to do this in order to make use of the NOTIFY/LISTEN > functionality as well. > > > 4) Implement a standard set of exceptions which can be thrown > > ex. if connection to back-end is interrupted or cannot be established > > within 30 seconds of the first attempt, throw. > > If you really want exceptions, sure. I don't like 'em myself, but I > can understand their advantages. > > > 5) I'm looking at making the libraries portable between FreeBSD, Solaris > > Linux and Win32. > > Please add BeOS that that list--I'll help keep it in line. > > > If anyone has suggestions/additions to this list it would be greatly > > appreciated! > > I'm very interested in helping with this (it is on my list of projects > and I've managed to stop adding new ones to the list for now). Should > we take this off-list, or keep it here? > > In either case, I'll spend some time formally thinking about my > perfect API and we can get together and compare notes... > > -- > Adam Haberlach | A billion hours ago, human life appeared on > adam@newsnipple.com | earth. A billion minutes ago, Christianity > http://www.newsnipple.com | emerged. A billion Coca-Colas ago was > '88 EX500 | yesterday morning. -1996 Coca-Cola Ann. Rpt. > > Randy Jonasz Software Engineer Click2net Inc. Web: http://www.click2net.com Phone: (905) 271-3550 "You cannot possibly pay a philosopher what he's worth, but try your best" -- Aristotle
>> If anyone has suggestions/additions to this list it would be greatly >> appreciated! > I'm very interested in helping with this (it is on my list of projects > and I've managed to stop adding new ones to the list for now). Should > we take this off-list, or keep it here? We could move it to pgsql-interfaces or setup a list on one of the free, web-based list engines. Joel
> > If anyone has suggestions/additions to this list it would be greatly > > appreciated! > > I'm very interested in helping with this (it is on my list of projects > and I've managed to stop adding new ones to the list for now). Should > we take this off-list, or keep it here? Certainly the PostgreSQL interfaces list is the best place to discuss, but hackers is ok for a period. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > > 2) Implement results as a returned object from pg_database
> > > result = db.exec();
> > > result >> field1 >> field2 >> field3;
> > > and
> > > field = result["field"];
> > > field = result[fieldnum];
Rogue Wave Software has an SQL C++ interface in dbtools.h++. It is
similar to what you describe. Here is a sample program:
#include <rw/db/db.h>
int main () { 1. RWDBDatabase enterpriseDB = RWDBManager :: database ("SYBASE",
"SYBASESERVER","ME", "PASSWORD", "DATA");
RWDBTable table1 = enterpriseDB.table("Actual_Sales");
2. RWDBReader table1Reader = table1.reader();
RWDBDatabase spreadsheet = RWDBManager :: database ("ODBC", "MS_EXCEL", "ME", "PASSWORD", "C:\mydir");
3. spreadsheet.createTable ("TMPSALES", table1.schema()); RWDBTable spreadsheetTable =
spreadsheet.table("TMPSALES");
4. RWDBInserter localInserter = spreadsheetTable.inserter(); while (table1Reader()) { localInserter <<
table1Reader;localInserter.execute(); }
...
5. /* Insert DDE code to plot your sales forecast, stored in the second spreadsheet, versus actual sales
now stored in the TMPSALES spreadsheet. */ }
There are white-papers describing the interface. It may be helpful for
ideas. You can see more at:
http://www.roguewave.com/products/xplatform/dbtools/
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026