[Qt-interest] subclassing Sql drivers (linking issue)

[André Somers]

Hi Thiago,

Thanks for your explanation; it makes a lot of sense.

What I am trying to do is basically extend the Qt SQL drivers to support
data definition language statements through the QSqlDriver::sqlStatement
(along with some other extensions). For this, I have written a template
class that uses the template argument as the class to derive from. This
template class defines and implements most of the additional stuff needed,
and it is then specialized per concrete driver. I end up with something like
this:

Template<typename SqlDriverBase>
ExtendedSqlDriverBase : public SqlDriverBase {
...
}

ExtendedMySqlDriver: public ExtendedSqlDriverBase<QMYSQLDriver> {
...
}

For this to work, I need to be able to inherit from the existing drivers.
Including the qt code into my own driver code works, but it would be nicer
if I would be able to link against them. Alternatively, I could go for an
encapsulation approach instead of subclassing. That would however require my
driver to load the plugin and get an instance of the driver independently
from QDatabase. Might work too, but not too nice either. Any other
suggestion that is more elegant? I really prefer not to copy any Qt code
into my own project, or modify the Qt code directly, as that will quickly
become a maintenance problem. I like being able to just install a new SDK
and be done :-)

André

-----Oorspronkelijk bericht-----
Van: qt-interest-bounces at trolltech.com
[mailto:qt-interest-bounces at trolltech.com] Namens Thiago Macieira
Verzonden: dinsdag 23 februari 2010 19:26
Aan: qt-interest at trolltech.com
Onderwerp: Re: [Qt-interest] subclassing Sql drivers (linking issue)

Em Terça-feira 23 Fevereiro 2010, às 17:27:22, Andre Somers escreveu:
> Thiago Macieira wrote:
> > Em Terça-feira 23 Fevereiro 2010, às 16:22:28, Andre Somers escreveu:
> >> Andre Somers wrote:
> >>> Andre Somers wrote:
> >>>> Hi,
> >>>> 
> >>>> I am trying to extend the Qt SQL drivers to add some 
> >>>> functionality. I have the thing compiling, but I run into a 
> >>>> problem when linking. I get
> > 
> >>>> lots of "undefined reference" errors like these:
> > Change Qt code and recompile the driver.
> > 
> > The driver is not a library. You cannot link to it.
> 
> Weird, since the project file says it is:
> 
> odbc.pro sets the target, and includes qsqldriverbase.pri 
> sqldriverbase.pri includes qpluginbase.pri qpluginbase.pri contains 
> TEMPLATE = lib
> 
> That would suggest that the driver *is* a lib. The mere fact that it 
> results in a .dll (on windows) also suggests this.

Not really. It's not a library, it's a plugin.

In all platforms Qt supports, libraries and plugins are both dynamically-
loadable libraries (DLL, dylib) / shared objects (so) -- it's the same
concept with different names. (The only one where it wasn't the case was Mac
OS X 10.2 and earlier, but those are not supported)

The difference between a library and a plugin is the interface that they
export. Especially on Windows, where no symbols are exported unless
explicitly marked so (__declspec(dllexport)).

For a library, besides the DLL you're going to find headers installed, which
contain the public interface of that library. All such classes are properly
exported (Q_CORE_EXPORT, Q_GUI_EXPORT, etc.) and usually documented. The
same applies to your libraries as well, if you're on Windows -- on other
platforms, qmake doesn't impose this on you.

For a plugin, however, there are no public headers. The classes are not
exported, so the DLL's symbol table is almost empty. What it will contain,
however, is a simple "plugin entry point": a C function that can be found
via dlsym or GetProcAddress. The plugin loader code will then call that
function and obtain an object that can be used (for Qt plugins, the plugin
"instance").

A plugin usually implements an interface defined in a library. The Qt SQL
drivers, for example, all derive from QSqlDriver. The rest of the code
interacts with the plugin only by the interface defined in this library.

Now, what I do find weird is that QtSql has headers for each plugin. Some of
the classes are exported, some aren't. And none of them is documented. I'm
wondering if those headers should be _p.h and not made public.

Bill, do you have an opinion?

> Still, I managed to solve this a bit less elegantly by including the 
> relevant parts of these .pro files into my own one, pulling in the Qt 
> driver code into my own drivers. This frees me from having to 
> re-modify the qt drivers time and time again with each qt version. At 
> least as long as their .pro files remain stable... At least the thing 
> compiles and links now, and the qt plugin mechanism seems to load the
driver OK.
> Next up is making sure it actually works of course...

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358