Horton

Thread

  1. C++ client libs

    Randy Jonasz <rjonasz@click2net.com> — 2000-10-03T18:47:45Z

    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 be established
   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

  2. Re: C++ client libs

    Randy Jonasz <rjonasz@click2net.com> — 2000-10-03T21:01:52Z

    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

  3. Re: C++ client libs

    Adam Haberlach <adam@newsnipple.com> — 2000-10-03T21:43:13Z

    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.

  4. Re: C++ client libs

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-10-09T02:32:24Z

    > > 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, Pennsylvania 19026

  5. Re: C++ client libs

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-10-09T07:36:52Z

    > > > 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, Pennsylvania 19026