Thread: [Cppcms-users] cppdb: getting the full query
Brought to you by:
artyom-beilis
From: augustin <aug...@ov...> - 2010-12-24 08:22:33
|
Hello, Like discussed previously for dbixx, cppdb lacks the possibility to get the full query (for either logging or debugging purposes). At least when an error is thrown, we should be able to get the full query that caused the error. The driver error is not explicit enough. cppdb_error should implement: std::string cppdb::cppdb_error::get_query() which would return the full SQL. Probably, a similar function should exist in cppdb::session (to get the full query even when no error is thrown. In many cases, it would make development easier. Thanks, Augustin. -- Friends: http://www.reuniting.info/ http://activistsolutions.org/ My projects: http://astralcity.org/ http://3enjeux.overshoot.tv/ http://linux.overshoot.tv/ http://overshoot.tv/ http://charityware.info/ http://masquilier.org/ http://openteacher.info/ http://minguo.info/ http://www.wechange.org/ http://searching911.info/ . |
From: Artyom <art...@ya...> - 2010-12-24 10:33:03
|
Currently this is not supported as: 1. In many cases the query just does not exists or invalid. 2. CppDB does not rewrite the query in most of cases as it uses prepared statements, so basically the query you give is the query that is passed That was different in case of dbixx which did rewrite most of queries. Artyom ----- Original Message ---- > From: augustin <aug...@ov...> > To: cpp...@li... > Sent: Fri, December 24, 2010 10:23:36 AM > Subject: [Cppcms-users] cppdb: getting the full query > > Hello, > > Like discussed previously for dbixx, cppdb lacks the possibility to get the > full query (for either logging or debugging purposes). > > At least when an error is thrown, we should be able to get the full query that > > caused the error. The driver error is not explicit enough. > > cppdb_error should implement: > std::string cppdb::cppdb_error::get_query() > which would return the full SQL. > > Probably, a similar function should exist in cppdb::session (to get the full > query even when no error is thrown. > > In many cases, it would make development easier. > > Thanks, > > > Augustin. > -- > Friends: http://www.reuniting.info/ http://activistsolutions.org/ > My projects: > http://astralcity.org/ http://3enjeux.overshoot.tv/ http://linux.overshoot.tv/ > > http://overshoot.tv/ http://charityware.info/ http://masquilier.org/ > http://openteacher.info/ http://minguo.info/ > http://www.wechange.org/ http://searching911.info/ > > > > > > > > > > > > > . > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Cppcms-users mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppcms-users > |
From: augustin <aug...@ov...> - 2010-12-24 13:27:39
|
On Friday 24 December 2010 06:32:56 pm Artyom wrote: > Currently this is not supported > 1. In many cases the query just does not exists or invalid. > > 2. CppDB does not rewrite the query in most of cases as it uses > prepared statements, so basically the query you give is the query that > is passed I hope you'll re-consider and support it. We almost never pass a ready-made query, but use dynamic queries most of the time. When we do: cppdb::result res = sql << "SELECT * FROM user WHERE id = ? << user_id; it's very useful in many circumstances to know which user_id was actually passed. Internally, cppdb must be creating the full query before passing it to the backend. I need to have the full query with the replacements made: "SELECT * FROM user WHERE id = 123" Moreover, in a real application, some queries can become increasingly complex and increasingly dynamic (e.g. see Drupal and some of its API like db_rewrite_query()...!) Often, in order to understand why we don't get the result we expect, we need to have the very exact query as run by the SQL server. One more thing: when an application crashes, or throws an error, generally we don't know which query in the code causes the problem. Looking at the error logs at some generic error message is not useful. Having the full query appended in the error logs would help to find the cause much more quickly. I don't understand the cppdb internals and don't understand your first point ("the query just does not exists or is invalid"). But surely, at some point you must be sending a full query to the server, so it should be fairly easy to retrieve it. Augustin. -- Friends: http://www.reuniting.info/ http://activistsolutions.org/ My projects: http://astralcity.org/ http://3enjeux.overshoot.tv/ http://linux.overshoot.tv/ http://overshoot.tv/ http://charityware.info/ http://masquilier.org/ http://openteacher.info/ http://minguo.info/ http://www.wechange.org/ http://searching911.info/ . |
From: Artyom <art...@ya...> - 2010-12-24 13:46:35
|
Hello, > We almost never pass a ready-made query, but use dynamic queries most of the > time. > > When we do: > cppdb::result res = sql << "SELECT * FROM user WHERE id = ? << user_id; > it's very useful in many circumstances to know which user_id was actually > passed. > Internally, cppdb must be creating the full query before passing it to the > backend. > I need to have the full query with the replacements made: > "SELECT * FROM user WHERE id = 123" That is exactly what you are not going to get as CppDB uses almost anywhere prepared statements, that means that query that is passed is actually: "SELECT * FROM user WHERE id = ?" And parameter was binded separately on the Specific DB API level, like PQexecParams or PQexecPrepared This gives significant performance boost (100%-200%) as statements are prepared only once and the parameters are transferred independently. So don't expect to make this helpful. Also you should remember that the query itself is not globally available so for example if result binding fails there is no way to get the query itself or in many cases the prepared statement already lost the information about the original query as it keeps its statement object rather then the query itself. > > Moreover, in a real application, some queries can become increasingly complex > and increasingly dynamic (e.g. see Drupal and some of its API like > db_rewrite_query()...!) > Often, in order to understand why we don't get the result we expect, we need > to have the very exact query as run by the SQL server. Generally it is good idea not to generate SQL queries on the fly but rather create a set of statements you use and pass parameters via prepared statements. > > I don't understand the cppdb internals and don't understand your first point > ("the query just does not exists or is invalid"). > But surely, at some point you must be sending a full query to the server, so > it should be fairly easy to retrieve it. This is exactly the point, it is not. It may become some server side object and the call actually would look like: exec prepared cppdb_stmt_3(123); This library has very different internals in comparison to dbixx. Artyom |
From: augustin <aug...@ov...> - 2010-12-24 13:53:37
|
Ok, thank you Artyom for your reply. My problem is that I have never worked with prepared statements. I guess now is the perfect opportunity for me to learn one more thing :) I'll check all of this out and code accordingly. Blessings, Augustin. -- Friends: http://www.reuniting.info/ http://activistsolutions.org/ My projects: http://astralcity.org/ http://3enjeux.overshoot.tv/ http://linux.overshoot.tv/ http://overshoot.tv/ http://charityware.info/ http://masquilier.org/ http://openteacher.info/ http://minguo.info/ http://www.wechange.org/ http://searching911.info/ . |