On 09/15/2010 12:02 PM, Mateusz Loskot wrote:
On 14/09/10 16:38, Roland Bock wrote:
On 09/14/2010 04:12 PM, Dominique Devienne wrote:
A good and established library already mentioned on this list in this domain ishttp://soci.sourceforge.net/, which uses modern C++ and Boost.
I've seen it. It is certainly one of the best I've seen so far.
FYI, the team is applying final changes and new release is coming very soon. If you'd like to try it, please check the version from Git repo - source code is considered as stable, only floating element is build system.
BTW, in case you haven't been aware of this initiative: std::rdb
http://mail-lists.crystalclearsoftware.com/listinfo.cgi/std_rdb-crystalclear...
I wasn't aware of that one. Is it in active development? The mailing list looks a bit forsaken.
I'm keenly tracking this thread, looking forward to seeing new SQL ideas.
OK, taking the first example from the SOCI project page: // --------------------------------------------------- sql<< "select name, salary from persons where id ="<< id, into(name), into(salary); // --------------------------------------------------- This is nice, but still requires attention where the compiler could help, if the table definition was known. Here is what it would look like in my version (assuming that I manage the transition to boost proto): // --------------------------------------------------- typedef table_persons<> persons; typedef select_record<persons, persons::name, persons::salary> record; vector<record> records = db.query() << select<record>() << where(t::id() == id); do_something(records.front().name_, records.front().salary_); // --------------------------------------------------- Here are the pros and cons of my approach that I am aware of * CON: It requires the compiler to have intimate knowledge of the table definition and you don't want to manually manage changes in the C++ table definition (even though it is not too ugly). Thus, some code generator is required in the build process. * CON: If you want to use nested selects, you would have to define "pseudo table classes" to use them (at least that is my current concept for that). Up to now, I cannot think of a way to do all the type-checking and named value provision without that. * PRO: No typo within a string like "select name, salary from persons where id = " will pass the compiler. * PRO: There is no chance that you mismatch the order of retrieved columns, e.g. into(salary), into(name). In this simple example, such an error is unlikely, but if you have, say, ten elements? Maybe it would make sense to add such a layer as an option to SOCI? Regards, Roland