Midgard-apache2. Refactoring.

I already blogged about libgda implemented in new midgard-core.
While it looks promising for command line applications it started to be real problem in Apache2 environment. First of all I began to refactor midgard-apache module with new GObject based API.

As soon as I began I realized something really bad happened:

GLib-GObject-WARNING **: cannot register existing type `midgard_connection'

The midgard-core API call in this case could be simple limited to two lines of code:

g_object_new(MIDGARD_TYPE_CONNECTION, NULL);
gda_client_open_connection_from_string(client, "MySQL", str, 0);

Why such two lines of code can trigger such warning? ( Keep in mind that this "simple warning" was only a start of endless critical errors reported and followed by segfaults ).

I started to check code, recompile midgard-core and midgard-apache with different flags. But none of this things seemed to help. I started to investigate libgda code and found that the source of the problem is GLib's GModule API. Well, rather Apache2 not being compiled with gmodule flags.

One is able to easily reproduce it with such simple code:

g_object_new(GDA_TYPE_CONNECTION, NULL);
g_module_open("/path/to/any/lib/module.so", G_MODULE_BIND_LAZY);

I tried libgda and evolution's plugin in my case. It perfectly breaks GType system.

OK, I decided to try this code not when midgard-apache module is initialized but when http request is made. And it seemed it worked. But not for a long time:

midgard-core (pid:14649):(WARNING): Unable to create the configuration file.
I/O error : Permission denied
I/O error : Permission denied
midgard-core (pid:14649):(WARNING): Error saving config data to /root/.libgda/config

It's not enough I am laying down, I must be kicked....
gda_client_open_connection_from_string in this case is a hack and this function creates configuration file , reads data from this file and when data ie read , file is cleaned. But it's not trivial when Apache's child is not running with root permission...

I started to write example codes to find any workaround quickly, and finally I changed midgard_connection and midgard_config code a bit, so some of API functions can easily be invoked even if no object instance was created. Manipulating with core's structures ( available as public API structures ) I managaed to create database connection using libgda API ( when module is initialized ) and create midgard_connection objects when http request is made.

So far it looks very good. Especially midgard_connection object looks good as its instance is created once and available as one object per virtual server ( Midgard1 module uses one connection structure per request). It looks like a very good start for future caching possibilities.