[Kommander-devel] Questions for seasoned C++ gurus

[Eric Laffoon]

Hi All,
I'm rewriting the database plugin for my immediate production use as a more 
robust and flexible tool, and to make a path to port to KDE4. In fact I'm 
specifically writing it with the Qt4 porting info at hand to be sure it is 
really easy to port. Anyway Here is my current problem. Amazingly I'm really 
close. Here's the compatibility (with existing plugin) query function.

bool Database::dbQuery(const QString& sql)
{
  if (!db->open())
    return 0;
  QSqlQuery query( sql );
  if (query.isActive())
    return 1;
  else
    return 0;
}

Now the way the existing plugin works we request the widget's text. Here's 
that function.

//the DCOP::text function
QString Database::dbQueryResult() const
{
  QString result = "";
  if (!query.isActive())
    return "No active query\n";
  else
  {
    QSqlRecord rec = db.record();
    int cols = rec.count();
    QString row;
    int r = 0;
    int i;
    while ( query.next() ) 
    {
      for (i=0; i<cols; ++i)
      {
        if (i == 0)
          row = rec.value(i).toString();
        else
          row = row + "\t" + rec.value(i).toString();
      }
      if (r > 0) result = result + "\n";
      result = result + row;
    }
    return result;
  }
}

You can probably see the problem... It should be this->query.isActive() right? 
I tried adding it to the header file as there are so many calls. Just 
achieving compatibility is over 350 lines of code, which I was surprised how 
fast I wrote. Anyway this doesn't work...

private:
  QSqlDatabase* db;
  QSqlQuery* query;

Don't ask why I thought it would work... Less typing. ;) Michal had someting 
similar to this using other functions from the library he was using. I tend 
to think this will be easier to write, but time will tell. 

I'm not entirely sure how best to do some things. One of my errors complained 
something was not a static member, which got me thinking. I'm sure I read how 
to do that once. I may have to change some choices given the complexity of 
these classes, or possibly have to do some type casting. What I'm sure of is 
that I need db and query to persist and be exposed. Here are the rules, or as 
best I can do without knowing my choices better.

db will probably only have one instance per widget and probably not change. 
While it's programatically possible to do more than one it's probably too 
confusing for me and for users and it's not really likely someome would be 
connecting to one database and then another.

query would have only one instance in the compatibility mode, but it would 
take on new data each time an SQL query was passed to it. 

I'm looking at creating a new widget for enhanced functionality and 
preparation for subquery relationships, standardized handling of browse, 
update and insert modes and automated relationships with widgets. This would 
most likely be one instance at a time with each loaded widget. 

If I can resolve this I can probably begin testing.
-- 
Eric Laffoon
Project Lead - kdewebdev module