Re: [gnome-db] Meta Store issue with MySQL.

[Vivien Malerba <vmalerba gmail com>]

2009/8/4 Bas Driessen <bas driessen xobas com>

On Mon, 2009-08-03 at 21:19 +1000, Bas Driessen wrote:

On Thu, 2009-07-30 at 16:17 +0200, Vivien Malerba wrote:

2009/7/30 Bas Driessen <bas driessen xobas com>

> 2009/7/30 Bas Driessen <bas driessen xobas com>
>
>>  Hello,
>>
>> My database is in MySQL. When I run the following command to rebuild the
>> MetaStore (which lives in a sqlite3 database):
>>
>> gda_connection_update_meta_store(connection, NULL, &error)
>>
>> I get the following error/warning:
>>
>> ** (process:22406): WARNING **: (+5): Wrong Holder value type, expected
>> type 'boolean' when value's type is 'string' (Provider ThreadWrapper)
>>
>>
>> and the MySQL table information is not in the MetaStore. In fact if I
>> do:
>>
>> select * from _tables;
>>
>> nothing shows up.
>>
>> Anyone else having this problem?
>>
>
> The reason for this error is that a SELECT statement internally run by the
> MySQL provider to get meta data returned a column of type string instead
> to
> a boolean. To solve this, the correction consists in locating the faulty
> SELECT, and use gda_connection_statement_execute_select_full() with an
> array
> of expected types for the columns instead of
> gda_connection_statement_execute_select(). This is already done at several
> places in gda-mysql-meta.c.
>
> If you want to try to correct it, and if you are in the master branch, you
> can use the definitions in
> libgda/providers-support/gda-meta-column-types.h
> (which is dynamically generated).
>
> Otherwise, I'd need to have more information to correct the problem
> myself.


OK, I will try to locate and correct the issue in libgda. Just wanted to
have confirmed first that this is an issue in libgda and not in my setup.

To help you, you can uncomment the line 2324 of the gda-meta-store.c file, so you'll get debug info about all the results the provider is returning for the meta store.

OK, I am a step further in this (I think). In file providers/mysql/gda-mysql-meta.c, line 717 the structure should be changed from:

GType col_types_views[] = {
                G_TYPE_STRING, G_TYPE_STRING, G_TYPE_STRING, G_TYPE_STRING,
                G_TYPE_STRING, G_TYPE_STRING, G_TYPE_NONE
        };

to:


GType col_types_views[] = {
                G_TYPE_STRING, G_TYPE_STRING, G_TYPE_STRING, G_TYPE_STRING,
                G_TYPE_STRING, G_TYPE_BOOLEAN, G_TYPE_NONE
        };

The original error will be gone and it will continue past the point where it stopped. However, there are now many new error messages:


(process:8055): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Type gchararray not mapped for value 0

(process:8055): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Type gint not mapped for value (null)

(process:8055): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Invalid column bind data type. 253

(this repeats many many times)
============


(process:8055): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Unable to get value for row 0 and column 10

** (process:8055): WARNING **: Type gint not mapped for value (null) (Provider ThreadWrapper)

As a rollback is triggered, the meta store is empty.

I have no idea if I am pretty close to have this all working, or if this whole area is still up for a re-write/under development.

See also my previous thread for a reproducible case of this issue.

Any comments/tips/hints?

Vivien,

You should have received a patch from Carlos that correct the issues with the MetaStore for the MySQL provider as discussed above. He sent me the patch as well and initial testing shows that the MetaStore builds OK now. Both full update as partial update works OK. It has my thumbs up to be applied to the master.

Ok, then I propose you apply it yourself, as I'm currently on holliday with limited internet access.
Thanks a lot to you and Carlos,

Vivien

Thanks,
Bas.