[RDP] Life with RDSqlQuery()

Fred Gleason fredg at paravelsystems.com
Mon Oct 8 13:18:27 EDT 2007


Howdy Folks:

I've just been spending a few very interesting hours discovering (and dealing 
with) some of the implications of Dan's shiny new RDSqlQuery implementation.  
I thought I'd pass some of my findings along.

1) DEBUGGING
In addition to providing automatic DB reconnect functionality, the new class 
turns out to be extremely useful for debugging.  Anytime *any* invalid SQL 
query is run, RDSqlQuery generates a 'DB Reconnect!' message on stderr.  This 
behavior has already allowed me to discover and swat a number of bugs that 
have been lurking in the code, some for more than two years.  It's so handy 
that I've gone ahead and added a line in 'lib/rddb.cpp' that prints the 
offending SQL statement to stderr as well.

2) MULTIPLE QUERIES
One side effect that is worth noting is what happens if a SQL error happens in 
the middle of an inner loop when the outer loop is also being driven by a DB 
query.  For example, consider the following snippet:

sql=<some-good-sql>;
q=new RDSqlQuery(sql);
while(q->next()) {
  sql=<some-bad-sql>
  q1=new RDSqlQuery(sql)
  while(q1->next()) {
    <do-some-stuff>
  }
  delete q1;
}
delete q;

This behaves quite differently with RDSqlQuery than with QSqlQuery.  
Previously, the behavior was the bad statement(s) in the inner loop simply 
didn't get executed.  The effect now however is that the entire outer loop 
gets aborted as soon as the first error in the inner loop is encountered 
(because the overall DB connection gets reset).  Now, this arguably shouldn't 
matter -- if the SQL is bad, things have already gone off the rails -- but 
one place where we rely on the earlier behavior is in the schema update code 
('rdadmin/createdb.cpp'), where it's convenient to be able to rerun the 
update during the development process (knowing that any changes that have 
already been made will simply be treated as an "error" and ignored).  
Accordingly, I've gone ahead and reverted the SQL calls in that code to use 
straight QSqlQuery().

3) FALSE POSITIVES
There are a couple of places I've found where 'false positive' SQL errors get 
generated (i.e. when dropping the import table in RDSvc before an import to 
ensure a clean environment).  In those cases (there are only a couple), I've 
reverted code to use QSqlQuery as well.

Bottom line on all of this:  if you notice something generating 'DB 
Reconnect!' messages, STOP AND FIND OUT WHY.  When the code is correct, this 
should never be seen.

And Dan, thanks for all the work on getting this into CVS.  Just as a 
quality-control tool, I think it's going to be worth the effort many times 
over.

Cheers!


|-------------------------------------------------------------------------|
| Frederick F. Gleason, Jr. |               Chief Developer               |
|                           |               Paravel Systems               |
|-------------------------------------------------------------------------|
|       The first duty of a revolutionary is to get away with it.         |
|                                          -- Abbie Hoffman               |
|-------------------------------------------------------------------------|


More information about the Rivendell-prog mailing list