Unexpected behavior when making multiple calls to rowset's begin() and end()

[soci]

Unexpected behavior when making multiple calls to rowset's begin() and end()

[mloskot]

@kfmfe04 It should work well. There is dedicated test19() for the rowset<> and std::distance() in common-tests.h which boils down to this:

rowset<row> rs = (sql.prepare << "select * from soci_test");
assert(5 == std::distance(rs.begin(), rs.end()));

Is it possible you are re-using the iterator? The doc on rowset says:

The rowset_iterator type is compatible with requirements
defined for input iterator category

Perhaps, you could post a concise and self-contained code sample, that could help to reproduce it.

[kfmfe04]

Thank you for the quick reply. I just found in the mailing list that the iterator type you have implemented is an input iterator. I can understand the use of an input iterator for caching purposes/optimization/general code (eg pulling in a gazillion rows), but for regular use, it seems less convenient than a forward iterator.

Let's take the case of your example above: once I call std::distance() on rs.begin() and rs.end(), I can no longer iterator through rs, correct? My testing seems to indicate this is true - and this is consistent with input iterators.

Do I start-over and generate another rowset? Or perhaps I need to allocate my own memory to store the data so that I can iterate through it like a forward iterator or know how many rows have been selected?

EDIT: ok - I am going to wrap soci::rowset in a class where calls to begin() will be marked. If begin() is called a second time, I will throw a std::runtime_exception(), asking the developer to create a new instance. It's ugly, but it'll do. It's okay to close out this issue. TY.

[kfmfe04]

As a work-around for limitations of an input iterator, I made a copy of the results:

typedef soci::rowset<ROW_TUPLE> rowset_type;
rowset_type rs = (session.prepare << m_qry);
std::copy( rs.begin(), rs.end(), std::back_inserter(m_v));

where ROW_TUPLE is an appropriate boost::tuple<>, and m_v is a std::vector<ROW_TUPLE>.

It would be nice if, in the future, there is an option in SOCI to select a container replacement for soci::rowset<> (in my case, that would be std::vector<>) to avoid the extra copy, but this workaround will work fine for now.

[mloskot]

I assume it can be closed as by design.

I'd suggest to open new ticket with proposal of improvements, if anything comes to mind.