----- Original Message ----- From: "Brock Peabody" <brock.peabody@npcinternational.com>
Hi Corwin,
Do you think our interface should support bi-directional iteration to avoid the pitfalls you mention with input iterators, or should we only support input iterators to support the broadest number of implementations?
I think we should support both an input iterator and a random access iterator. The reason for this is that, as mentioned, for many databases by far the most efficient operation is to just retrieve the set of records via a forward-only cursor and not provide any guarantee that the order of rows is repeatable. As soon as you have to maintain a specific order for the records (which is what a bi-directional iterator implies) then the database often has to take a huge performance hit. As mentioned, some drivers implement this by downloading all records to the local computer (yuck!), locking the entire table or other ugly things. Hopefully the driver is smart and can do version tracking but it is hard to be sure. That, to me, is why logically you have two C++ iterator types that make sense: an input iterator and a random access iterator.
Do you know of any databases whose native APIs don't support bi-directional iteration?
Well, for example MS Access used to not support this via ODBC, but even if they do support it I don't think it is a good idea to *require* it for the iterator since this can have big performance costs. Also there are some kinds of result sets which may be forward only by definition. Result sets from stored procedures come to mind here.
If you get a chance you might check out the project in boost-sandbox/database.
I've browsed through it somewhat online. I need to look through the boost site docs and find out how to connect up to the sandbox via CVS.