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(at)zembu(dot)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