Discussion:
[soci-users] Ways to deal with many columns
Jordan Woehr
2013-06-22 21:49:07 UTC
Permalink
I'm using SOCI to access a PostgreSQL database. One particular table that I
have has 72 columns. My question is how does one best deal with so many
columns?

I've determined that for selecting, using the SOCI dynamic result set is
probably best. In this way I can loop over the columns.

However, for inserting I'm having difficulty. What I want to achieve is
something as follows:

int vals[NUM_VALS];
statement st = s.prepare << "INSERT INTO table (c0, c1, c2, ...) VALUES (";
for(int i = 0; i < NUM_VALS; ++i)
st << vals[i];
st << ")";
st.execute();

Is anything like this possible? I've had no luck finding any way of dealing
with large numbers of columns in an easy way.

Jordan
Vadim Zeitlin
2013-06-22 21:57:31 UTC
Permalink
On Sat, 22 Jun 2013 15:49:07 -0600 Jordan Woehr <***@gmail.com> wrote:

JW> However, for inserting I'm having difficulty. What I want to achieve is
JW> something as follows:
JW>
JW> int vals[NUM_VALS];
JW> statement st = s.prepare << "INSERT INTO table (c0, c1, c2, ...) VALUES (";
JW> for(int i = 0; i < NUM_VALS; ++i)
JW> st << vals[i];
JW> st << ")";
JW> st.execute();
JW>
JW> Is anything like this possible?

Why not? You just need to postpone the statement construction until after
you build the full SQL script in this loop. And you can call
statement::use() in the loop too.

Regards,
VZ
Jordan Woehr
2013-06-22 22:30:11 UTC
Permalink
Post by Vadim Zeitlin
JW> However, for inserting I'm having difficulty. What I want to achieve is
JW>
JW> int vals[NUM_VALS];
JW> statement st = s.prepare << "INSERT INTO table (c0, c1, c2, ...) VALUES (";
JW> for(int i = 0; i < NUM_VALS; ++i)
JW> st << vals[i];
JW> st << ")";
JW> st.execute();
JW>
JW> Is anything like this possible?
Why not? You just need to postpone the statement construction until after
you build the full SQL script in this loop. And you can call
statement::use() in the loop too.
Well. That turned out to be really easy. Thanks!

I guess the disconnect for me was

statement st = s.prepare ...;

I didn't realize that the statement object was constructed from
prepare_type. Seems pretty obvious now.

Loading...