On Wed, 2009-08-05 at 11:41 +0200, Vivien Malerba wrote:

> 
> 
> 
> 2009/8/4 Bas Driessen <[email protected]>
> 
>         
>         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 <[email protected]>
>         > > 
>         > >         
>         > >         > 2009/7/30 Bas Driessen <[email protected]>
>         > >         >
>         > >         >>  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 
> 
>         

Roger that, will do. Enjoy your holiday and drop us a line when you are
back in the captains chair :)

Bas.

_______________________________________________
gnome-db-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Reply via email to