Re: RFC C++ Interface

Thanks for responding.  I've made some comments below.

On Wed, 13 Dec 2000, Nathan Myers wrote:

> On Wed, Dec 13, 2000 at 03:16:28PM -0500, Randy Jonasz wrote:
> > On Tue, 12 Dec 2000, Nathan Myers wrote:
> > > On Tue, Dec 12, 2000 at 05:28:46PM -0500, Bruce Momjian wrote:
> > > > > I was co-architect of the Rogue Wave Dbtools.h++ interface design
> > > > > ... The design is really showing its age.
> > > > Can you suggest areas that should be changed?
> > > As I recall, we were much more fond of operator overloading then than is
> > > considered tasteful or wise today. Also, there was no standard for how
> > > iterators ought to work, then, whereas today one needs unusually good
> > > reasons to depart from the STL style.
> >
> > Interesting comments.  I can see using the STL framework for iterating
> > through result sets being one way to go.  Would something like:
> >
> > vector<pgrows>table = pgdb.exec("Select * from foo");
> > vector<pgrows>::iterator row;
> > vector<pgrows>::iterator end = table.end();
> >
> > for( row = table.begin(); row != end; ++row ) {
> >   *row >> field1 >> field2;
> >   //do something with fields
> > }
> >
> > be along the lines you were thinking?
>
> No.  The essence of STL is its iterator interface framework.
> (The containers and algorithms that come with STL should be seen
> merely as examples of how to use the iterators.)  A better
> example would be
>
>   Postgres::Result_iterator end;
>   for (Postgres::Result_iterator it = pgdb.exec("Select * from foo");
>        it != end; ++it) {
>     int field1;
>     string field2;
>     *it >> field1 >> field2;
>     // do something with fields
>   }
>
> (although this still involves overloading ">>").
> The points illustrated above are:
>
The above I like very much although it implies a synchronous connection to
the back end.  This can be worked around though by providing both a
synchronous and an asynchronous interface rather than using just one.  I
don't see any problems with overloading ">>" or "[]" to obtain the value
of a column.

> 1. Shoehorning the results of a query into an actual STL container is
>    probably a Bad Thing.  Users who want that can do it themselves
>    with std::copy().

On further thought I agree with you here.  Returning an iterator to a
result container would be much more efficient than what I originally
proposed.
>
> 2. Lazy extraction of query results is almost always better than
>    aggressive extraction.  Often you don't actually care about
>    the later results, and you may not have room for them anyhow.
>
> Rather than the generic result iterator type illustrated above, with
> conversion to C++ types on extraction via ">>", I would prefer to use
> a templated iterator type so that the body of the loop would look more
> like
>
>   // do something with it->field1 and it->field2
>
> or
>
>   // do something with it->field1() and it->field2()
>
This creates the problem of having public member variables and/or having a
mechanism to clone enough variables as there were columns returned in an
SQL statement.  I much prefer the earlier methods of accessing these
values.

> However, it can be tricky to reconcile compile-time type-safety with
> the entirely runtime-determined result of a "select".  Probably you
> could put in conformance checking where the result of exec() gets
> converted to the iterator, and throw an exception if the types don't
> match.
>
> Nathan Myers
> ncm@zembu.com
>
>
>

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