Working directly with structs (insert and query of full rows)?

[emmenlau]

I very much like the abstraction that taopq achieves. One thing I'm missing is to be able to work directly with structs. Lately I've seen the reflection used by the cista library that makes it possible to generate table creation and insert statements directly from c++ structs (albeit with a slightly special syntax). A compilable example is given here:
https://www.onlinegdb.com/BkEgNzpkN

Would that be something you could see in taopq?

[d-frey]

I don't think it is a good fit for taoPQ. In my experience, the idea always sounds nice but in practice you need more complicated queries than just getting an "object". And if you want this to work nicely in the C++ syntax, things become very complicated quickly. Years ago I wrote an object-oriented "in-language" system (where you add "persistent" to the members of a class and a PERL script that "parses" your code to generate the real C++ code from it. IMHO it was a disaster, even though it did work. But I never liked the experience. When years later (and one company later) I was more free to decide how to write C++ wrappers for PostgreSQL and Oracle, I used a design already much closer to taoPQ and finally, with all the experience, I wrote taoPQ from scratch. I don't think I'll ever want to go back to modelling my database in (pseudo-)C++.

[emmenlau]

Thanks @d-frey , this is a very valuable insight. We're very much at the beginning of that journey and so far, I've found it very cumbersome to code all the SQL <-> C++ mapping from scratch. But I can see your point, and its appreciated!

[d-frey]

What we are using in our production code actually works like this:

• All SQL statements are in the config file with a symbolic name (an identifier)
• The code loads the config and registers these as prepared statements
• The code then executes the prepared statements with a bunch of parameters
• Executing prepared statements can be significantly faster than executing non-prepared statements
• The code doesn't know anything about SQL, no table names, row names, etc. - it's all in the config!
• We have wrappers that guarantee type-safety when calling an SQL statement and converting the result (in case of a SELECT-statement) into the corresponding C++ types

Given that we can modify/improve the actual SQL statements simply by changing the config has saved our butts a couple of times in production.

[emmenlau]

That sounds actually really great! I did not think of this idea, but its slick and powerful! Awesome!