Nabble - Gnome - DB

Re: GNOME 3.0 and GSeal corrections

2009-12-07T13:37:29Z

2009/12/2 Vivien Malerba <vmalerba@...>:

> 2009/12/2 Daniel Espinosa <esodan@...>:
>> I using
>>
>> make CFLAGS+="-DGSEAL_ENABLE"
>>
>> for to check GNOME 3.0 compliant and found, few direct access to
>> GObject members and properties, and for 3.0 we must use the API for
>> get/set properties. I'd found some one but stoped when found the
>> following error:
>>
>> gdaui-data-cell-renderer-boolean.c:392: error: invalid storage class
>> for function ‘gdaui_data_cell_renderer_boolean_activate’
>> gdaui-data-cell-renderer-boolean.c:410: error: expected declaration or
>> statement at end of input
>>
>> I've tried to figured out the problem and made some corrections on
>> this file (and others for the current state) found in the attached
>> patch, but may you knows more about why is this error is still there,
>> I can't continue from here because this error stops compilation
>> process.
>>
>
> I'll check this ASAP, thanks for the patch.
>
> Vivien
>

This is now done (in git master branch), with a few cases where GTK
does not yet have the correct API for GTK_WIDGET_SET_FLAGS() and
GTK_WIDGET_MAPPED().

Regards,

Vivien
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Re: GObject Introspection Support and Gnome 3.0

2009-12-02T00:45:13Z

2009/12/2 Daniel Espinosa <esodan@...>:
> How is desirable to have support of GObjectInstrospection in a Gnome
> component for the upcomming Gnome 3.0 release?
>
> What if I need to break ABI to get "easy support" of
> GObjectIntrospection for a library?

I would be very surprised if there wasn't any way to add introspection
support without breaking the ABI, and I really don't want to break the
ABI now.

So please try to find a way for the few objects which are a problem
and make special (not automatically generated) rules for them (if I
remember correctly there are ony 2 or 3).

Thanks a lot for the work you put in bringing introspection support to Libgda.

Vivien
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Re: GNOME 3.0 and GSeal corrections

2009-12-02T00:41:25Z

2009/12/2 Daniel Espinosa <esodan@...>:

> I using
>
> make CFLAGS+="-DGSEAL_ENABLE"
>
> for to check GNOME 3.0 compliant and found, few direct access to
> GObject members and properties, and for 3.0 we must use the API for
> get/set properties. I'd found some one but stoped when found the
> following error:
>
> gdaui-data-cell-renderer-boolean.c:392: error: invalid storage class
> for function ‘gdaui_data_cell_renderer_boolean_activate’
> gdaui-data-cell-renderer-boolean.c:410: error: expected declaration or
> statement at end of input
>
> I've tried to figured out the problem and made some corrections on
> this file (and others for the current state) found in the attached
> patch, but may you knows more about why is this error is still there,
> I can't continue from here because this error stops compilation
> process.
>

I'll check this ASAP, thanks for the patch.

Vivien
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Re: SqlBuilder feedback

2009-12-02T00:37:26Z

2009/12/2 Murray Cumming <murrayc@...>:

> On Wed, 2009-11-25 at 22:36 +0100, Vivien Malerba wrote:
>> >> I would append _id to the existing functions, so, for instance:
>> >> gda_sql_builder_add_field()
>> >> would become
>> >> gda_sql_builder_add_field_id()
>> >> and then add real gda_sql_builder_add_field() and
>> >> gda_sql_builder_add_field_value() functions like above, but without
>> >> "easy" in their name.
>> >
>> > Thoughts? I don't want to give up on this API. It could be very useful
>> > in glom an in general.
>> >
>>
>> You can now check commit
>> http://git.gnome.org/cgit/libgda/commit/?id=9ecb4bc9f8d4cfc2dad31a5109b610f6988c2fd9
>> which has the new API.
>
> Thanks. That's much better.
>
> How about doing the same for the other functions, such as
> gda_sql_builder_select_add_target(), gda_sql_builder_add_cond(), etc?
>
> I can do that if you like.

That'd be great, yes.

Thanks,

Vivien
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Re: SqlBuilder feedback

2009-12-02T00:21:55Z

On Wed, 2009-11-25 at 22:36 +0100, Vivien Malerba wrote:

> >> I would append _id to the existing functions, so, for instance:
> >> gda_sql_builder_add_field()
> >> would become
> >> gda_sql_builder_add_field_id()
> >> and then add real gda_sql_builder_add_field() and
> >> gda_sql_builder_add_field_value() functions like above, but without
> >> "easy" in their name.
> >
> > Thoughts? I don't want to give up on this API. It could be very useful
> > in glom an in general.
> >
>
> You can now check commit
> http://git.gnome.org/cgit/libgda/commit/?id=9ecb4bc9f8d4cfc2dad31a5109b610f6988c2fd9
> which has the new API.

Thanks. That's much better.

How about doing the same for the other functions, such as
gda_sql_builder_select_add_target(), gda_sql_builder_add_cond(), etc?

I can do that if you like.

--
murrayc@...
www.murrayc.com
www.openismus.com

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

GNOME 3.0 and GSeal corrections

2009-12-01T20:54:36Z

I using

make CFLAGS+="-DGSEAL_ENABLE"

for to check GNOME 3.0 compliant and found, few direct access to
GObject members and properties, and for 3.0 we must use the API for
get/set properties. I'd found some one but stoped when found the
following error:

gdaui-data-cell-renderer-boolean.c:392: error: invalid storage class
for function ‘gdaui_data_cell_renderer_boolean_activate’
gdaui-data-cell-renderer-boolean.c:410: error: expected declaration or
statement at end of input

I've tried to figured out the problem and made some corrections on
this file (and others for the current state) found in the attached
patch, but may you knows more about why is this error is still there,
I can't continue from here because this error stops compilation
process.

--
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)

[0002-GSeal-Corrections.patch]

diff --git a/doc/C/tmpl/gda-connection.sgml b/doc/C/tmpl/gda-connection.sgml index 3515eaa..98eb8fa 100644 --- a/doc/C/tmpl/gda-connection.sgml +++ b/doc/C/tmpl/gda-connection.sgml @@ -172,7 +172,6 @@ A connection to a database @GDA_CONNECTION_CANT_LOCK_ERROR: @GDA_CONNECTION_TASK_NOT_FOUND_ERROR: @GDA_CONNECTION_UNSUPPORTED_THREADS_ERROR: -@GDA_CONNECTION_CLOSED_ERROR:  <para> diff --git a/doc/C/tmpl/gda-data-model-bdb.sgml b/doc/C/tmpl/gda-data-model-bdb.sgml index b5b5860..18f41f1 100644 --- a/doc/C/tmpl/gda-data-model-bdb.sgml +++ b/doc/C/tmpl/gda-data-model-bdb.sgml @@ -29,16 +29,8 @@ virtual methods). </para> - - -<para> - -</para> - - -<para> - -</para> +@object: +@priv:  <para> diff --git a/doc/C/tmpl/gda-data-select.sgml b/doc/C/tmpl/gda-data-select.sgml index 429a8f3..ea59224 100644 --- a/doc/C/tmpl/gda-data-select.sgml +++ b/doc/C/tmpl/gda-data-select.sgml @@ -172,13 +172,3 @@ Data models returned by the execution of a SELECT statement @Returns: - -<para> - -</para> - -@model: -@error: -@Returns: - - diff --git a/doc/C/tmpl/gda-set.sgml b/doc/C/tmpl/gda-set.sgml index 9265bbb..8e34d45 100644 --- a/doc/C/tmpl/gda-set.sgml +++ b/doc/C/tmpl/gda-set.sgml @@ -187,16 +187,6 @@ Container for several values @Returns: - -<para> - -</para> - -@set: -@pos: -@Returns: - -  <para> diff --git a/doc/C/tmpl/gda-sql-builder.sgml b/doc/C/tmpl/gda-sql-builder.sgml index b50dc6b..ae48595 100644 --- a/doc/C/tmpl/gda-sql-builder.sgml +++ b/doc/C/tmpl/gda-sql-builder.sgml @@ -54,11 +54,6 @@ gda_sql_builder_add_cond2 (b, 5, GDA_SQL_OPERATOR_TYPE_AND, 3, 4); // whole expr </para> - -<para> - -</para> -  <para> @@ -103,172 +98,10 @@ gda_sql_builder_add_cond2 (b, 5, GDA_SQL_OPERATOR_TYPE_AND, 3, 4); // whole expr </para> @builder: -@field_name: -@type: -@Varargs: - - - -<para> - -</para> - -@builder: -@field_name: -@value: - - - -<para> - -</para> - -@builder: @field_id: @value_id: - -<para> - -</para> - -@builder: -@id: -@func_name: -@Varargs: -@Returns: - - - -<para> - -</para> - -@builder: -@id: -@func_name: -@args: -@args_size: -@Returns: - - - -<para> - -</para> - -@builder: -@id: -@string: -@Returns: - - - -<para> - -</para> - -@builder: -@id: -@dh: -@type: -@Varargs: -@Returns: - - - -<para> - -</para> - -@builder: -@id: -@dh: -@value: -@Returns: - - - -<para> - -</para> - -@builder: -@id: -@param_name: -@type: -@nullok: -@Returns: - - - -<para> - -</para> - -@builder: -@id: -@test_expr: -@else_expr: -@Varargs: -@Returns: - - - -<para> - -</para> - -@builder: -@id: -@test_expr: -@else_expr: -@when_array: -@then_array: -@args_size: -@Returns: - - - -<para> - -</para> - -@builder: -@id: -@sqlst: -@steal: -@Returns: - - - -<para> - -</para> - -@builder: -@id: -@op: -@op1: -@op2: -@op3: -@Returns: - - - -<para> - -</para> - -@builder: -@id: -@op: -@op_ids: -@op_ids_size: -@Returns: - -  <para> @@ -290,17 +123,6 @@ gda_sql_builder_add_cond2 (b, 5, GDA_SQL_OPERATOR_TYPE_AND, 3, 4); // whole expr @Returns: - -<para> - -</para> - -@builder: -@field_name: -@table_name: -@alias: - -  <para> @@ -336,22 +158,3 @@ gda_sql_builder_add_cond2 (b, 5, GDA_SQL_OPERATOR_TYPE_AND, 3, 4); // whole expr @collation_name: - -<para> - -</para> - -@builder: -@sqlst: -@steal: - - - -<para> - -</para> - -@builder: -@compound_type: - - diff --git a/doc/C/tmpl/gda-sql-statement.sgml b/doc/C/tmpl/gda-sql-statement.sgml index 1eac851..ac300f2 100644 --- a/doc/C/tmpl/gda-sql-statement.sgml +++ b/doc/C/tmpl/gda-sql-statement.sgml @@ -802,6 +802,8 @@ Specifies the type of functions passed to gda_sql_any_part_foreach(). @any: @field_name: @validity_meta_table_column: +@_gda_reserved1: +@_gda_reserved2:  <para> @@ -855,6 +857,8 @@ Specifies the type of functions passed to gda_sql_any_part_foreach(). @any: @table_name: @validity_meta_object: +@_gda_reserved1: +@_gda_reserved2:  <para> @@ -908,6 +912,8 @@ Specifies the type of functions passed to gda_sql_any_part_foreach(). @any: inheritance structure @function_name: name of the function , in the form [[catalog.]schema.]function_name @args_list: list of #GdaSqlExpr expressions, one for each argument +@_gda_reserved1: +@_gda_reserved2:  <para> @@ -970,6 +976,8 @@ Specifies the type of functions passed to gda_sql_any_part_foreach(). @any: inheritance structure @operator_type: @operands: list of #GdaSqlExpr operands +@_gda_reserved1: +@_gda_reserved2:  <para> @@ -1070,6 +1078,8 @@ Specifies the type of functions passed to gda_sql_any_part_foreach(). @when_expr_list: list of #GdaSqlExpr, one for each WHEN clause @then_expr_list: list of #GdaSqlExpr, one for each THEN clause @else_expr: default expression for the CASE +@_gda_reserved1: +@_gda_reserved2:  <para> @@ -1121,6 +1131,8 @@ Specifies the type of functions passed to gda_sql_any_part_foreach(). @as: alias @validity_meta_object: @validity_meta_table_column: +@_gda_reserved1: +@_gda_reserved2:  <para> @@ -1197,6 +1209,8 @@ Specifies the type of functions passed to gda_sql_any_part_foreach(). @table_name: table name part of @expr if @expr represents a table @as: alias @validity_meta_object: +@_gda_reserved1: +@_gda_reserved2:  <para> @@ -1270,6 +1284,8 @@ Specifies the type of functions passed to gda_sql_any_part_foreach(). @position: represents a join between a target at (pos < @position) and the one at @position @expr: joining expression, or %NULL @use: list of #GdaSqlField pointers to use when joining, or %NULL +@_gda_reserved1: +@_gda_reserved2:  <para> @@ -1335,6 +1351,8 @@ Specifies the type of functions passed to gda_sql_any_part_foreach(). @any: inheritance structure @targets: list of #GdaSqlSelectTarget @joins: list of #GdaSqlSelectJoin +@_gda_reserved1: +@_gda_reserved2:  <para> @@ -1398,6 +1416,8 @@ Specifies the type of functions passed to gda_sql_any_part_foreach(). @expr: expression to order on @asc: TRUE is ordering is ascending @collation_name: name of the collation to use for ordering +@_gda_reserved1: +@_gda_reserved2:  <para> diff --git a/doc/C/tmpl/gda-virtual-connection.sgml b/doc/C/tmpl/gda-virtual-connection.sgml index 04f084a..d896fe2 100644 --- a/doc/C/tmpl/gda-virtual-connection.sgml +++ b/doc/C/tmpl/gda-virtual-connection.sgml @@ -33,17 +33,6 @@ This is a base virtual class for all virtual connection implementations @Returns: - -<para> - -</para> - -@virtual_provider: -@options: -@error: -@Returns: - -  <para> diff --git a/doc/C/tmpl/gdaui-basic-form.sgml b/doc/C/tmpl/gdaui-basic-form.sgml index e87db0b..2abc54e 100644 --- a/doc/C/tmpl/gdaui-basic-form.sgml +++ b/doc/C/tmpl/gdaui-basic-form.sgml @@ -39,11 +39,6 @@ Form widget mapping the values contained in a #GdaSet @arg1: @arg2: - -<para> - -</para> -  <para> diff --git a/doc/C/tmpl/gdaui-cloud.sgml b/doc/C/tmpl/gdaui-cloud.sgml index 266ff61..6123bd1 100644 --- a/doc/C/tmpl/gdaui-cloud.sgml +++ b/doc/C/tmpl/gdaui-cloud.sgml @@ -17,96 +17,3 @@ Cloud widget  - -<para> - -</para> - - - -<para> - -</para> - -@gdauicloud: the object which received the signal. -@arg1: - - -<para> - -</para> - -@gdauicloud: the object which received the signal. - - -<para> - -</para> - - -<para> - -</para> - - -<para> - -</para> - - -<para> - -</para> - - -<para> - -</para> - - -<para> - -</para> - -@model: -@label_column: -@weight_column: -@Returns: - - - -<para> - -</para> - -@cloud: -@mode: - - - -<para> - -</para> - -@cloud: -@Returns: - - - -<para> - -</para> - -@cloud: -@filter: - - - -<para> - -</para> - -@cloud: -@Returns: - - diff --git a/doc/C/tmpl/provider-support.sgml b/doc/C/tmpl/provider-support.sgml index 937bd21..147ac38 100644 --- a/doc/C/tmpl/provider-support.sgml +++ b/doc/C/tmpl/provider-support.sgml @@ -323,25 +323,6 @@ Methods dedicated to implementing providers @newstate: - -<para> - -</para> - -@cnc: - - - -<para> - -</para> - -@directory: -@filename: -@auto_unlink: -@Returns: - -  <para> diff --git a/libgda-ui/data-entries/gdaui-data-cell-renderer-bin.c b/libgda-ui/data-entries/gdaui-data-cell-renderer-bin.c index 7120031..7bd6215 100644 --- a/libgda-ui/data-entries/gdaui-data-cell-renderer-bin.c +++ b/libgda-ui/data-entries/gdaui-data-cell-renderer-bin.c @@ -128,9 +128,8 @@ gdaui_data_cell_renderer_bin_init (GdauiDataCellRendererBin *cell) cell->priv->dh = NULL; cell->priv->type = GDA_TYPE_BLOB; cell->priv->editable = FALSE; - GTK_CELL_RENDERER (cell)->mode = GTK_CELL_RENDERER_MODE_ACTIVATABLE; - GTK_CELL_RENDERER (cell)->xpad = 2; - GTK_CELL_RENDERER (cell)->ypad = 2; + g_object_set (G_OBJECT (cell), "mode", GTK_CELL_RENDERER_MODE_ACTIVATABLE, + "xpad", 2, "ypad", 2, NULL); } static void @@ -361,15 +360,21 @@ gdaui_data_cell_renderer_bin_render (GtkCellRenderer *cell, GtkCellRendererClass *pixbuf_class = g_type_class_peek (GTK_TYPE_CELL_RENDERER_PIXBUF); (pixbuf_class->render) (cell, window, widget, background_area, cell_area, expose_area, flags); - - if (GDAUI_DATA_CELL_RENDERER_BIN (cell)->priv->to_be_deleted) - gtk_paint_hline (widget->style, + + if (GDAUI_DATA_CELL_RENDERER_BIN (cell)->priv->to_be_deleted) { + GtkStyle *style; + guint xpad; + + g_object_get (G_OBJECT(widget), "style", &style, "xpad", &xpad, NULL); + gtk_paint_hline (style, window, GTK_STATE_SELECTED, cell_area, widget, "hline", - cell_area->x + cell->xpad, cell_area->x + cell_area->width - cell->xpad, + cell_area->x + xpad, cell_area->x + cell_area->width - xpad, cell_area->y + cell_area->height / 2.); + g_object_unref (style); + } } diff --git a/libgda-ui/data-entries/gdaui-data-cell-renderer-boolean.c b/libgda-ui/data-entries/gdaui-data-cell-renderer-boolean.c index f886993..2626de8 100644 --- a/libgda-ui/data-entries/gdaui-data-cell-renderer-boolean.c +++ b/libgda-ui/data-entries/gdaui-data-cell-renderer-boolean.c @@ -57,8 +57,8 @@ static gboolean gdaui_data_cell_renderer_boolean_activate (GtkCellRenderer GdkEvent *event, GtkWidget *widget, const gchar *path, - GdkRectangle *background_area, - GdkRectangle *cell_area, + const GdkRectangle *background_area, + const GdkRectangle *cell_area, GtkCellRendererState flags); enum { @@ -126,9 +126,8 @@ gdaui_data_cell_renderer_boolean_init (GdauiDataCellRendererBoolean *cell) cell->priv->dh = NULL; cell->priv->type = G_TYPE_BOOLEAN; cell->priv->editable = FALSE; - GTK_CELL_RENDERER (cell)->mode = GTK_CELL_RENDERER_MODE_ACTIVATABLE; - GTK_CELL_RENDERER (cell)->xpad = 2; - GTK_CELL_RENDERER (cell)->ypad = 2; + g_object_set (G_OBJECT (cell), "mode", GTK_CELL_RENDERER_MODE_ACTIVATABLE, + "xpad", 2, "ypad", 2, NULL); } static void @@ -367,13 +366,17 @@ gdaui_data_cell_renderer_boolean_render (GtkCellRenderer *cell, (toggle_class->render) (cell, window, widget, background_area, cell_area, expose_area, flags); - if (GDAUI_DATA_CELL_RENDERER_BOOLEAN (cell)->priv->to_be_deleted) - gtk_paint_hline (widget->style, + if (GDAUI_DATA_CELL_RENDERER_BOOLEAN (cell)->priv->to_be_deleted) { + GtkStyle *style; + guint xpad; + + g_object_get (G_OBJECT(widget), "style", &style, "xpad", &xpad, NULL); + gtk_paint_hline (style, window, GTK_STATE_SELECTED, cell_area, widget, "hline", - cell_area->x + cell->xpad, cell_area->x + cell_area->width - cell->xpad, + cell_area->x + xpad, cell_area->x + cell_area->width - xpad, cell_area->y + cell_area->height / 2.); } @@ -383,19 +386,21 @@ gdaui_data_cell_renderer_boolean_activate (GtkCellRenderer *cell, GdkEvent *event, GtkWidget *widget, const gchar *path, - GdkRectangle *background_area, - GdkRectangle *cell_area, + const GdkRectangle *background_area, + const GdkRectangle *cell_area, GtkCellRendererState flags) { - if (GDAUI_DATA_CELL_RENDERER_BOOLEAN (cell)->priv->editable) { - GtkCellRendererClass *toggle_class = g_type_class_peek (GTK_TYPE_CELL_RENDERER_TOGGLE); + gboolean editable; + g_object_get (G_OBJECT(cell), "editable", &editable, NULL); + if (editable) { gboolean retval, active; GValue *value; - retval = (toggle_class->activate) (cell, event, widget, path, background_area, cell_area, flags); + retval = gtk_cell_renderer_activate (cell, event, widget, path, background_area, cell_area, flags); active = gtk_cell_renderer_toggle_get_active (GTK_CELL_RENDERER_TOGGLE (cell)); - g_value_set_boolean (value = gda_value_new (G_TYPE_BOOLEAN), ! active); + value = gda_value_new (G_TYPE_BOOLEAN); + g_value_set_boolean (value, ! active); g_signal_emit (G_OBJECT (cell), toggle_cell_signals[CHANGED], 0, path, value); gda_value_free (value); return retval; diff --git a/tools/browser/doc/tmpl/browser-connection.sgml b/tools/browser/doc/tmpl/browser-connection.sgml index 9fbafa4..c18c9ee 100644 --- a/tools/browser/doc/tmpl/browser-connection.sgml +++ b/tools/browser/doc/tmpl/browser-connection.sgml @@ -35,6 +35,10 @@ An opened connection </para> +@: +@: +@: + @browserconnection: the object which received the signal. @arg1: @arg2: @@ -44,6 +48,8 @@ An opened connection </para> +@: + @browserconnection: the object which received the signal.  @@ -51,6 +57,9 @@ An opened connection </para> +@: +@: + @browserconnection: the object which received the signal. @arg1: @@ -59,6 +68,8 @@ An opened connection </para> +@: + @browserconnection: the object which received the signal.  @@ -142,18 +153,6 @@ An opened connection @Returns: - -<para> - -</para> - -@bcnc: -@sql: -@start: -@end: -@Returns: - -  <para> diff --git a/tools/browser/doc/tmpl/browser-core.sgml b/tools/browser/doc/tmpl/browser-core.sgml index 4148dae..fa061d8 100644 --- a/tools/browser/doc/tmpl/browser-core.sgml +++ b/tools/browser/doc/tmpl/browser-core.sgml @@ -43,6 +43,9 @@ Singleton holding the global browser information </para> +@: +@: + @browsercore: the object which received the signal. @arg1: @@ -51,6 +54,9 @@ Singleton holding the global browser information </para> +@: +@: + @browsercore: the object which received the signal. @arg1: diff --git a/tools/browser/doc/tmpl/browser-favorites.sgml b/tools/browser/doc/tmpl/browser-favorites.sgml index 3146364..5878868 100644 --- a/tools/browser/doc/tmpl/browser-favorites.sgml +++ b/tools/browser/doc/tmpl/browser-favorites.sgml @@ -130,19 +130,6 @@ Favorites management @fav: - -<para> - -</para> - -@bfav: -@session_id: -@contents: -@out_fav: -@error: -@Returns: - -  <para> diff --git a/tools/browser/doc/tmpl/browser-window.sgml b/tools/browser/doc/tmpl/browser-window.sgml index cff4433..26f2c57 100644 --- a/tools/browser/doc/tmpl/browser-window.sgml +++ b/tools/browser/doc/tmpl/browser-window.sgml @@ -57,7 +57,6 @@ Top level browser window @bwin: @context: @text: -@auto_clear: @Returns:

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

GObject Introspection Support and Gnome 3.0

2009-12-01T19:43:11Z

How is desirable to have support of GObjectInstrospection in a Gnome
component for the upcomming Gnome 3.0 release?

What if I need to break ABI to get "easy support" of
GObjectIntrospection for a library?

--
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los
cuates: LIBRE)
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Re: Status of Oracle support..

2009-11-29T15:35:12Z

On Sun, 2009-11-29 at 16:55 +0100, Vivien Malerba wrote:
>
> Thanks for the examples, it helped correct the problem which was that
> the GdaDataModel's column's types
> were not set even though they were computed. (BTW I had to install the
> vala compiler to change the name and password, and I was impressed
> with it,I might try it in the future...)

Ooops.. didn't think about that. I've always wanted to learn C but don't
exactly have any mentors around to bounce my questions off of. I can
read it "ok" but wouldn't be able to write anything useful. Thankfully,
vala is a bit easier for me to follow and the fact that it generates C
will be a helpful tool for me to learn C while I'm at it. It's a win win
for me. I'm glad you like it as well.

> Anyway, the correction is now in git (master branch), tell me if it's
> OK for you.

Worked perfectly.. I appreciate the quick response!!

> You're probably right the attachment might have been removed. Next
> time you can fill a bug report in bugzilla so anyone can access the
> code.

Excellent idea.. I'll remember that next time.

SMF 8D

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Re: Status of Oracle support..

2009-11-29T07:55:38Z

2009/11/29 Shawn Ferris <shawn.ferris@...>:

> On Sat, 2009-11-28 at 16:17 +0100, Vivien Malerba wrote:
>> > Also, I've created a simple program that creates a result.
>> > gda_data_model_dump_as_string displays the results accuraretly, however,
>> > in a GdauiGrid, all the values say <non-printable> with the exception of
>> > nulls. (those cells are empty of course)
>>
>> If you can send it to me I can try to reproduce and correct the problem.
>
> Wasn't sure how much you wanted, so I'm including the vapi that I
> generated, obviously the vala code as well as the generated c code from
> vala. Also, there are two examples.. for the most part they're identical
> except that one dispays the results in a grid, and the other via
> dump_as_string.
>
> Also, the Makefile should compile the examples without requiring vala at
> all. Again, just didn't know how much you wanted to see.

Thanks for the examples, it helped correct the problem which was that
the GdaDataModel's column's types
were not set even though they were computed. (BTW I had to install the
vala compiler to change the name and password, and I was impressed
with it,I might try it in the future...)

Anyway, the correction is now in git (master branch), tell me if it's
OK for you.

>
> PS: Also wasn't sure whether I should CC the list for something like
> this or not? (I presume the attachement will be stripped leaving a
> fairly empty email)
>

You're probably right the attachment might have been removed. Next
time you can fill a bug report in bugzilla so anyone can access the
code.

Regards,

Vivien
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Re: Status of Oracle support..

2009-11-28T07:17:25Z

2009/11/28 Shawn Ferris <shawn.ferris@...>:
> Hey All --
>
> I've downloaded and installed libgda-4.1.3 and enabled Oracle support
> using Oracle instant client 11.2.0. I'm running into issues and I'm
> wondering if I'm trying to use it to prematurely?

The Oracle provider has been re-written after the 4.0 release and is
still not used widely so you can
expect some bugs, yes.

>
> For instance, the add connection dialog doesn't seem to support adding
> Oracle connections. You can select the oracle provider, but the database
> name input doesn't include TNSNAME which causes the connection to fail.
> Manually updating the configuration works fine however.

Right, I'll correct this ASAP.

>
> Also, I've created a simple program that creates a result.
> gda_data_model_dump_as_string displays the results accuraretly, however,
> in a GdauiGrid, all the values say <non-printable> with the exception of
> nulls. (those cells are empty of course)

If you can send it to me I can try to reproduce and correct the problem.

>
> I should also mention that I'm trying this in Vala and I haven't ruled
> out vapi issues, but thought I'd quickly ask in case these are known
> issues and the oracle support isn't ready for prime time.. (The
> generated C looks good to me, so I don't think that's the issue.. but
> I'll continue to debug it of course)

I'd rather blame Libgda then Vala for this ;)

Regards,

Vivien
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Status of Oracle support..

2009-11-27T17:50:01Z

Hey All --

I've downloaded and installed libgda-4.1.3 and enabled Oracle support
using Oracle instant client 11.2.0. I'm running into issues and I'm
wondering if I'm trying to use it to prematurely?

For instance, the add connection dialog doesn't seem to support adding
Oracle connections. You can select the oracle provider, but the database
name input doesn't include TNSNAME which causes the connection to fail.
Manually updating the configuration works fine however.

Also, I've created a simple program that creates a result.
gda_data_model_dump_as_string displays the results accuraretly, however,
in a GdauiGrid, all the values say <non-printable> with the exception of
nulls. (those cells are empty of course)

I should also mention that I'm trying this in Vala and I haven't ruled
out vapi issues, but thought I'd quickly ask in case these are known
issues and the oracle support isn't ready for prime time.. (The
generated C looks good to me, so I don't think that's the issue.. but
I'll continue to debug it of course)

Thanks.. appreciate it!

Shawn

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

problem on enums compiling libgda on mingw/msys under windows

2009-11-15T02:27:17Z

libgda version 4.1.3

gda-enum-types.h, and other glib-mkenums generated files, look like this

G_BEGIN_DECLS
C:/msys/1.0/* enumerations from "gda-config.h" *//n
GType gda_config_error_get_type (void);
#define GDA_TYPE_CONFIG_ERROR (gda_config_error_get_type())
C:/msys/1.0/* enumerations from "gda-connection-event.h" *//n
GType gda_connection_event_type_get_type (void);
#define GDA_TYPE_CONNECTION_EVENT_TYPE (gda_connection_event_type_get_type())
GType gda_connection_event_code_get_type (void);
#define GDA_TYPE_CONNECTION_EVENT_CODE (gda_connection_event_code_get_type())
C:/msys/1.0/* enumerations from "gda-connection.h" *//n
GType gda_connection_error_get_type (void);
#define GDA_TYPE_CONNECTION_ERROR (gda_connection_error_get_type())
GType gda_connection_options_get_type (void);
#define GDA_TYPE_CONNECTION_OPTIONS (gda_connection_options_get_type())
...

i think it is a problem of mingw/msys, because there's similar issue
on using xml-catalog

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Re: SqlBuilder feedback

2009-11-09T01:19:23Z

2009/11/9 Murray Cumming <murrayc@...>:

> On Mon, 2009-10-26 at 18:21 +0100, Murray Cumming wrote:
>> On Mon, 2009-10-26 at 10:04 +0100, Vivien Malerba wrote:
>> > 2009/10/25 Murray Cumming <murrayc@...>:
>> > > I've looked at the new GdaSqlBuilder API and I have some thoughts.
>> > >
>> > > Firstly, I think that the IDs are exposed too often. I can see how the
>> > > ID could have some use to an application programmer, but it should not
>> > > be the main way to use the API.
>> > >
>> > > At the least, this (pseudo-code) is annoying:
>> > > gda_sql_builder_add_field(builder,
>> > > gda_sql_builder_add_id(builder, 0, "sometable.somefield") );
>> > >
>> > > This would be nicer:
>> > > gda_sql_builder_add_field(builder, "somefield",
>> > > "sometable" (optional))
>> > > would be nicer.
>> > >
>> > > In subsequent calls, GdaSqlBuilder would use the same ID automatically.
>> > >
>> > >
>> > > The current API gets even more long-winded when dealing with values too,
>> > > for UPDATE commands:
>> > > gda_sql_builder_add_field(builder,
>> > > gda_sql_builder_add_id(builder, 0, "sometable.somefield") );
>> > > gda_sql_builder_add_expr(builder, 0, NULL, 123) );
>> > >
>> > > This would be simpler:
>> > > gda_sql_builder_add_field_value(builder, "somefield",
>> > > "sometable" (optional), 123);
>> >
>> > Using ID allows the API to be kept to a minimum number of functions,
>> > while allowing one to build very complex statements, so I want to keep
>> > them as they are, but I agree there is a need to have some more "daily
>> > usage" API to have less lines of code. There are 2 ways of doing this:
>> > either create some real functions or use macros. Even though I like to
>> > keep the number of methods to a minimal, using macros here can lead to
>> > difficult debugging times as the macros could get complex, so I
>> > propose to add new "higher level" API, starting with:
>>
>> I can't imagine why you would ever want to use macros instead of
>> functions. That way lies madness.
>>
>> > void gda_sql_builder_easy_add_field (GdaSqlBuilder *builder, const
>> > gchar *field_table, const gchar *field_name, GType type, ...)
>> > and
>> > void gda_sql_builder_easy_add_field_value (GdaSqlBuilder *builder,
>> > const gchar *field_table, const gchar *field_name, GValue *value)
>>
>> I hate the use of "easy" in API names. Just make it easy - you don't
>> need to call it easy. That just makes the API look weird and
>> inconsistent.
>>
>> I would append _id to the existing functions, so, for instance:
>> gda_sql_builder_add_field()
>> would become
>> gda_sql_builder_add_field_id()
>> and then add real gda_sql_builder_add_field() and
>> gda_sql_builder_add_field_value() functions like above, but without
>> "easy" in their name.
>
> Thoughts? I don't want to give up on this API. It could be very useful
> in glom an in general.
>

I just did not have the time to implement the API, I've been working
on a new provider which
has eaten way more time than I had anticipated.

Vivien
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Re: SqlBuilder feedback

2009-11-09T01:14:37Z

On Mon, 2009-10-26 at 18:21 +0100, Murray Cumming wrote:

> On Mon, 2009-10-26 at 10:04 +0100, Vivien Malerba wrote:
> > 2009/10/25 Murray Cumming <murrayc@...>:
> > > I've looked at the new GdaSqlBuilder API and I have some thoughts.
> > >
> > > Firstly, I think that the IDs are exposed too often. I can see how the
> > > ID could have some use to an application programmer, but it should not
> > > be the main way to use the API.
> > >
> > > At the least, this (pseudo-code) is annoying:
> > > gda_sql_builder_add_field(builder,
> > > gda_sql_builder_add_id(builder, 0, "sometable.somefield") );
> > >
> > > This would be nicer:
> > > gda_sql_builder_add_field(builder, "somefield",
> > > "sometable" (optional))
> > > would be nicer.
> > >
> > > In subsequent calls, GdaSqlBuilder would use the same ID automatically.
> > >
> > >
> > > The current API gets even more long-winded when dealing with values too,
> > > for UPDATE commands:
> > > gda_sql_builder_add_field(builder,
> > > gda_sql_builder_add_id(builder, 0, "sometable.somefield") );
> > > gda_sql_builder_add_expr(builder, 0, NULL, 123) );
> > >
> > > This would be simpler:
> > > gda_sql_builder_add_field_value(builder, "somefield",
> > > "sometable" (optional), 123);
> >
> > Using ID allows the API to be kept to a minimum number of functions,
> > while allowing one to build very complex statements, so I want to keep
> > them as they are, but I agree there is a need to have some more "daily
> > usage" API to have less lines of code. There are 2 ways of doing this:
> > either create some real functions or use macros. Even though I like to
> > keep the number of methods to a minimal, using macros here can lead to
> > difficult debugging times as the macros could get complex, so I
> > propose to add new "higher level" API, starting with:
>
> I can't imagine why you would ever want to use macros instead of
> functions. That way lies madness.
>
> > void gda_sql_builder_easy_add_field (GdaSqlBuilder *builder, const
> > gchar *field_table, const gchar *field_name, GType type, ...)
> > and
> > void gda_sql_builder_easy_add_field_value (GdaSqlBuilder *builder,
> > const gchar *field_table, const gchar *field_name, GValue *value)
>
> I hate the use of "easy" in API names. Just make it easy - you don't
> need to call it easy. That just makes the API look weird and
> inconsistent.
>
> I would append _id to the existing functions, so, for instance:
> gda_sql_builder_add_field()
> would become
> gda_sql_builder_add_field_id()
> and then add real gda_sql_builder_add_field() and
> gda_sql_builder_add_field_value() functions like above, but without
> "easy" in their name.

Thoughts? I don't want to give up on this API. It could be very useful
in glom an in general.

--
murrayc@...
www.murrayc.com
www.openismus.com

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Re: SqlBuilder feedback

2009-10-26T10:21:20Z

On Mon, 2009-10-26 at 10:04 +0100, Vivien Malerba wrote:

> 2009/10/25 Murray Cumming <murrayc@...>:
> > I've looked at the new GdaSqlBuilder API and I have some thoughts.
> >
> > Firstly, I think that the IDs are exposed too often. I can see how the
> > ID could have some use to an application programmer, but it should not
> > be the main way to use the API.
> >
> > At the least, this (pseudo-code) is annoying:
> > gda_sql_builder_add_field(builder,
> > gda_sql_builder_add_id(builder, 0, "sometable.somefield") );
> >
> > This would be nicer:
> > gda_sql_builder_add_field(builder, "somefield",
> > "sometable" (optional))
> > would be nicer.
> >
> > In subsequent calls, GdaSqlBuilder would use the same ID automatically.
> >
> >
> > The current API gets even more long-winded when dealing with values too,
> > for UPDATE commands:
> > gda_sql_builder_add_field(builder,
> > gda_sql_builder_add_id(builder, 0, "sometable.somefield") );
> > gda_sql_builder_add_expr(builder, 0, NULL, 123) );
> >
> > This would be simpler:
> > gda_sql_builder_add_field_value(builder, "somefield",
> > "sometable" (optional), 123);
>
> Using ID allows the API to be kept to a minimum number of functions,
> while allowing one to build very complex statements, so I want to keep
> them as they are, but I agree there is a need to have some more "daily
> usage" API to have less lines of code. There are 2 ways of doing this:
> either create some real functions or use macros. Even though I like to
> keep the number of methods to a minimal, using macros here can lead to
> difficult debugging times as the macros could get complex, so I
> propose to add new "higher level" API, starting with:

I can't imagine why you would ever want to use macros instead of
functions. That way lies madness.

> void gda_sql_builder_easy_add_field (GdaSqlBuilder *builder, const
> gchar *field_table, const gchar *field_name, GType type, ...)
> and
> void gda_sql_builder_easy_add_field_value (GdaSqlBuilder *builder,
> const gchar *field_table, const gchar *field_name, GValue *value)

I hate the use of "easy" in API names. Just make it easy - you don't
need to call it easy. That just makes the API look weird and
inconsistent.

I would append _id to the existing functions, so, for instance:
gda_sql_builder_add_field()
would become
gda_sql_builder_add_field_id()
and then add real gda_sql_builder_add_field() and
gda_sql_builder_add_field_value() functions like above, but without
"easy" in their name.

--
murrayc@...
www.murrayc.com
www.openismus.com

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Re: SqlBuilder feedback

2009-10-26T02:04:55Z

2009/10/25 Murray Cumming <murrayc@...>:

> I've looked at the new GdaSqlBuilder API and I have some thoughts.
>
> Firstly, I think that the IDs are exposed too often. I can see how the
> ID could have some use to an application programmer, but it should not
> be the main way to use the API.
>
> At the least, this (pseudo-code) is annoying:
> gda_sql_builder_add_field(builder,
> gda_sql_builder_add_id(builder, 0, "sometable.somefield") );
>
> This would be nicer:
> gda_sql_builder_add_field(builder, "somefield",
> "sometable" (optional))
> would be nicer.
>
> In subsequent calls, GdaSqlBuilder would use the same ID automatically.
>
>
> The current API gets even more long-winded when dealing with values too,
> for UPDATE commands:
> gda_sql_builder_add_field(builder,
> gda_sql_builder_add_id(builder, 0, "sometable.somefield") );
> gda_sql_builder_add_expr(builder, 0, NULL, 123) );
>
> This would be simpler:
> gda_sql_builder_add_field_value(builder, "somefield",
> "sometable" (optional), 123);

Using ID allows the API to be kept to a minimum number of functions,
while allowing one to build very complex statements, so I want to keep
them as they are, but I agree there is a need to have some more "daily
usage" API to have less lines of code. There are 2 ways of doing this:
either create some real functions or use macros. Even though I like to
keep the number of methods to a minimal, using macros here can lead to
difficult debugging times as the macros could get complex, so I
propose to add new "higher level" API, starting with:

void gda_sql_builder_easy_add_field (GdaSqlBuilder *builder, const
gchar *field_table, const gchar *field_name, GType type, ...)
and
void gda_sql_builder_easy_add_field_value (GdaSqlBuilder *builder,
const gchar *field_table, const gchar *field_name, GValue *value)

What do you think?

Vivien
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

SqlBuilder feedback

2009-10-25T15:56:15Z

I've looked at the new GdaSqlBuilder API and I have some thoughts.

Firstly, I think that the IDs are exposed too often. I can see how the
ID could have some use to an application programmer, but it should not
be the main way to use the API.

At the least, this (pseudo-code) is annoying:
gda_sql_builder_add_field(builder,
gda_sql_builder_add_id(builder, 0, "sometable.somefield") );

This would be nicer:
gda_sql_builder_add_field(builder, "somefield",
"sometable" (optional))
would be nicer.

In subsequent calls, GdaSqlBuilder would use the same ID automatically.

The current API gets even more long-winded when dealing with values too,
for UPDATE commands:
gda_sql_builder_add_field(builder,
gda_sql_builder_add_id(builder, 0, "sometable.somefield") );
gda_sql_builder_add_expr(builder, 0, NULL, 123) );

This would be simpler:
gda_sql_builder_add_field_value(builder, "somefield",
"sometable" (optional), 123);

--
murrayc@...
www.murrayc.com
www.openismus.com

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Re: libgda 4.1.3 crash on windows

2009-10-22T05:47:32Z

2009/10/21 Andrea Zagli <azagli@...>:
> provider: postgresql
> os: windows xp pro sp3
> libgda version: 4.1.3
> postgresql version: 8.4.1
>
> i think that libgda crash when in a table there is a field of type double
> (float8) (or real) and it isn't NULL
>
> i tried from my program and from gda-browser

Beware if you try from your own program that the DLL I produce are
linked with MSVCRT80.DLL and if you're not
using mingw to compile your program (for example Visual Studio), then
you'll experience some problems.

I'll try myself ASAP.

>
> unfortunately i can't provide a stack trace because gdb returns only 2 ??
> rows; is libgda on windows compiled with debug info?

I think there is some debug info as I use the same compilation
environment as for Linux, but I'll check.

Vivien
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

libgda 4.1.3 crash on windows

2009-10-21T09:08:42Z

provider: postgresql
os: windows xp pro sp3
libgda version: 4.1.3
postgresql version: 8.4.1

i think that libgda crash when in a table there is a field of type
double (float8) (or real) and it isn't NULL

i tried from my program and from gda-browser

unfortunately i can't provide a stack trace because gdb returns only 2
?? rows; is libgda on windows compiled with debug info?

on linux it works

thanks in advance

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Re: Compiling with MinGW under MSYS

2009-10-12T02:55:34Z

2009/10/12 Brecht Sanders <brecht@...>:

>
> Hi,
> I just tried to compile both new releases (4.05 and 4.1.3) and both fail
> with the output below.
> I'm on the official MinGW 4.4.0.
> The errors mention missing files, but the names of these files are identical
> for both libgda 4.05 and 4.1.3.
> Any idea what is happening?
>
>
> I don't know. However it looks like all the reported missing files are
> actually flags that are passed on the command line, so you can try
> removing those flags, and then see why there are there (specially if
> they are only present for the MySQL provider).
>
>
> You're right!
> Whe I replace the line below in providers/mysql/Makefile:
> MYSQL_CFLAGS = "-I/mingw/include/mysql" "-D_WINDOWS" "/MT" "/Zi" "/O2"
> "/Ob1" "/D" "NDEBUG" "-DDBUG_OFF" "/wd4996"
> with:
> MYSQL_CFLAGS = "-I/mingw/include/mysql" "-D_WINDOWS" "-DNDEBUG"
> "-DDBUG_OFF"
> it does compile nicely.
> Any idea why it uses these Windows-style parameters (using slash)?

No...

>
> Now I have linking problems though:
> Creating library file:
> .libs/libgda-mysql.dll.a.libs/gda-mysql-parser.o:gda-mysql-parser.c:(.text+0xdf):
> undefined reference to `gda_lemon_mysql_parserTrace'

This function is defined in the (automatically generated) parser.c
file in providers/mysql. Can you check the file not missing, and if
it's there that the mentionned function is present? If so, then can
you also check the parser.o file is there
and contains the symbol?

Vivien
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Re: Compiling with MinGW under MSYS

2009-10-12T01:49:52Z

Hi,
I just tried to compile both new releases (4.05 and 4.1.3) and both fail
with the output below.
I'm on the official MinGW 4.4.0.
The errors mention missing files, but the names of these files are identical
for both libgda 4.05 and 4.1.3.
Any idea what is happening?


I don't know. However it looks like all the reported missing files are
actually flags that are passed on the command line, so you can try
removing those flags, and then see why there are there (specially if
they are only present for the MySQL provider).

You're right!
Whe I replace the line below in providers/mysql/Makefile:
MYSQL_CFLAGS = "-I/mingw/include/mysql" "-D_WINDOWS" "/MT" "/Zi" "/O2" "/Ob1" "/D" "NDEBUG" "-DDBUG_OFF" "/wd4996"
with:
MYSQL_CFLAGS = "-I/mingw/include/mysql" "-D_WINDOWS" "-DNDEBUG" "-DDBUG_OFF"
it does compile nicely.
Any idea why it uses these Windows-style parameters (using slash)?

Now I have linking problems though:
Creating library file: .libs/libgda-mysql.dll.a.libs/gda-mysql-parser.o:gda-mysql-parser.c:(.text+0xdf): undefined reference to `gda_lemon_mysql_parserTrace'

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Re: Compiling with MinGW under MSYS

2009-10-12T01:01:52Z

2009/10/12 Brecht Sanders <brecht@...>:
> Hi,
> I just tried to compile both new releases (4.05 and 4.1.3) and both fail
> with the output below.
> I'm on the official MinGW 4.4.0.
> The errors mention missing files, but the names of these files are identical
> for both libgda 4.05 and 4.1.3.
> Any idea what is happening?

I don't know. However it looks like all the reported missing files are
actually flags that are passed on the command line, so you can try
removing those flags, and then see why there are there (specially if
they are only present for the MySQL provider).

Vivien
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Compiling with MinGW under MSYS

2009-10-11T23:55:45Z

Hi,
I just tried to compile both new releases (4.05 and 4.1.3) and both fail
with the output below.
I'm on the official MinGW 4.4.0.
The errors mention missing files, but the names of these files are
identical for both libgda 4.05 and 4.1.3.
Any idea what is happening?
Regards
Brecht Sanders

libtool: compile: gcc "-DPACKAGE_NAME=\"GNU Data Access\""
-DPACKAGE_TARNAME=\"libgda\" -DPACKAGE_VERSION=\"4.0.5\"
"-DPACKAGE_STRING=\"GNU Data Access 4.0.5\""
-DPACKAGE_BUGREPORT=\"gnome-db-list@...\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DSIZEOF_UNSIGNED_INT=4 -DSIZEOF_UNSIGNED_LONG_INT=4 -DSTDC_HEADERS=1
-DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DGETTEXT_PACKAGE=\"libgda-4.0\"
-DHAVE_LOCALE_H=1 -DHAVE_BIND_TEXTDOMAIN_CODESET=1 -DHAVE_GETTEXT=1
-DHAVE_DCGETTEXT=1 -DENABLE_NLS=1 -DUSING_MINGW=1 -DHAVE_MYSQL=1
-DHAVE_POSTGRES=1 -DHAVE_FIREBIRD=1 -DHAVE_LDAP=1 -DHAVE_LIBSOUP=1
-DHAVE_READLINE=1 -DHAVE_HISTORY=1 -I. -I. -I../.. -I../../libgda
-I../.. -mms-bitfields -I/mingw/include/glib-2.0
-I/mingw/lib/glib-2.0/include -I/mingw/include/libxml2 -I/mingw/include
-DLIBGDA_ABI_NAME=\"libgda-4.0\" -I/mingw/include/mysql -D_WINDOWS /MT
/Zi /O2 /Ob1 /D NDEBUG -DDBUG_OFF /wd4996 -DLIBGDA_WIN32
-I/mingw/include/glib-2.0 -I/mingw/include/mysql -I/mingw/include/oracle
-Duint=guint -MT gda-mysql-blob-op.lo -MD -MP -MF
.deps/gda-mysql-blob-op.Tpo -c gda-mysql-blob-op.c -DDLL_EXPORT -DPIC
-o .libs/gda-mysql-blob-op.o
gcc.exe: D:/Prog/MinGW-mSys/MT: No such file or directory
gcc.exe: D:/Prog/MinGW-mSys/Zi: No such file or directory
gcc.exe: D:/Prog/MinGW-mSys/O2: No such file or directory
gcc.exe: D:/Prog/MinGW-mSys/Ob1: No such file or directory
gcc.exe: NDEBUG: No such file or directory
gcc.exe: D:/Prog/MinGW-mSys/wd4996: No such file or directory
make[2]: *** [gda-mysql-ddl.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
gcc.exe: D:/Prog/MinGW-mSys/MT: No such file or directory
gcc.exe: D:/Prog/MinGW-mSys/Zi: No such file or directory
gcc.exe: D:/Prog/MinGW-mSys/O2: No such file or directory
gcc.exe: D:/Prog/MinGW-mSys/Ob1: No such file or directory
gcc.exe: NDEBUG: No such file or directory
gcc.exe: D:/Prog/MinGW-mSys/wd4996: No such file or directory
make[2]: *** [gda-mysql-blob-op.lo] Error 1
make[2]: Leaving directory `/home/win32/libgda-4.0.5/providers/mysql'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/win32/libgda-4.0.5/providers'
make: *** [install-recursive] Error 1

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Libgda 4.1.3 released

2009-10-11T03:20:58Z

I'm pleased to announce version 4.1.3 of Libgda, a development version
which will lead to a 4.2 release.

Short description:
------------------------
Libgda is a (relatively small) database access library:
* a wrapper like ODBC but with more features to access several database engines
* a general data model to use CVS or XML files
* a meta data extractor (to know all about database objects in a comman way)
* features several tools: an SQL console application (like mysql, psql
or sqlite3 consoles), a graphical database browser, and a control
center
* relies on GLib, coded in C, its API is easy to use
* optionnally includes some graphical widgets (based on GTK+) for data
bound representations
and some graphical tools

Changes from 4.1.2
--------------------------
- GdaBrowser improvement
- UI extension corrections
- libgda's core improvements: better BLOB handling, better API for
GdaSqlBuilder,
GdaDataSelect
- misc bug fixes
- Translations:
- de (Mario Blättermann, Christian Kirbach)
- es (Jorge González)

Notes:
--------
* This is unstable development release. While it has had
a bit of testing, there are certainly plenty of bugs
remaining to be found. This release should not be used
in production.

* Installing this version will overwrite your existing
copy of Libgda 4. If you have problems, you'll need to
reinstall it.

* Libgda 4.2 will be source and binary compatible with
the 4.0 series.

* Bugs should be reported to http://bugzilla.gnome.org.

See the http://live.gnome.org/ChooseLibgdaSQLite page for additionnal
information about choosing
between Libgda and SQLite when you need a database API.

You can find more information at the projects' homepage
(http://www.gnome-db.org), or you can ask any question/propose
anything you want in the GNOME-DB mailing list, which is available at
http://mail.gnome.org/mailman/listinfo/gnome-db-list
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Libgda 4.0.5 released

2009-10-11T03:19:13Z

I'm pleased to announce version 4.0.5 of Libgda, which is a
maintenance release of the 4.0 serie.

Short description:
------------------------
Libgda is a (relatively small) database access library:
* a wrapper like ODBC but with more features to access several database engines
* a general data model to use CVS or XML files
* a meta data extractor (to know all about database objects in a comman way)
* comes with an SQL console application (like mysql, psql or sqlite3 consoles)
* relies on GLib, coded in C, its API is easy to use

Changes from 4.0.4
---------------------------
- Improved SQLite provider (avoid connection locking and
better BLOB support)
- Misc corrections (GdaBlobOp, virtual provider, GdaDataSelect)
- documentation updates

Tarballs are available at http://ftp.gnome.org/pub/GNOME/sources/libgda/4.0
Pease note that Win32 archives are also available at
http://ftp.gnome.org/pub/GNOME/binaries/win32/

See the http://live.gnome.org/ChooseLibgdaSQLite page for additionnal
information about choosing
between Libgda and SQLite when you need a database API.

You can find more information at the projects' homepage
(http://www.gnome-db.org), or you can ask any question/propose
anything you want in the GNOME-DB mailing list, which is available at
http://mail.gnome.org/mailman/listinfo/gnome-db-list
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Fwd: More SqlBuilder stuff

2009-10-07T09:18:18Z

---------- Forwarded message ----------
From: Vivien Malerba <vmalerba@...>
Date: 2009/10/7
Subject: Re: [gnome-db] More SqlBuilder stuff
To: Johannes Schmid <jhs@...>

2009/10/7 Johannes Schmid <jhs@...>:

> Hi Vivien!
>
> I was trying to convert a rather complicated SQL into GdaSqlBuilder
> statements but got stuck a bit:
>
>
> SELECT "albums"."album_id", "albums"."name", "albums"."artist_id",
> "relationship_artist"."name", "albums"."publisher_id",
> "relationship_publisher"."name",
> "albums"."year", "albums"."comments" FROM "albums" LEFT JOIN
> "publishers" AS "relationship_publisher"
> ON ("albums"."publisher_id" =
> "relationship_publisher"."publishers_id")
> LEFT JOIN "artists" AS "relationship_artist" ON ("albums"."artist_id" =
> "relationship_artist"."artist_id") WHERE "albums"."album_id" = 1 */
>
> I got to the point of the first LEFT JOIN rather quickly but then I have
> no real idea how to continue. This is what I have so far (it's in C++, I
> can convert it to C if that's easier for you):
>
> http://de.pastebin.ca/1600971

here is the C version, sorry I don't have the time to try the C++ version:

b = gda_sql_builder_new (GDA_SQL_STATEMENT_SELECT);

/* selected fields */
gda_sql_builder_add_field (b, gda_sql_builder_add_id (b, 0,
"albums.album_id"), 0);
gda_sql_builder_add_field (b, gda_sql_builder_add_id (b, 0,
"albums.name"), 0);
gda_sql_builder_add_field (b, gda_sql_builder_add_id (b, 0,
"albums.artist_id"), 0);
gda_sql_builder_add_field (b, gda_sql_builder_add_id (b, 0,
"relationship_artist.name"), 0);
gda_sql_builder_add_field (b, gda_sql_builder_add_id (b, 0,
"albums.publisher_id"), 0);
gda_sql_builder_add_field (b, gda_sql_builder_add_id (b, 0,
"relationship_publisher.name"), 0);
gda_sql_builder_add_field (b, gda_sql_builder_add_id (b, 0,
"albums.year"), 0);
gda_sql_builder_add_field (b, gda_sql_builder_add_id (b, 0,
"albums.comments"), 0);

/* targets */
gda_sql_builder_select_add_target (b, 1,
gda_sql_builder_add_id (b,
0, "albums"),
NULL);
gda_sql_builder_select_add_target (b, 2,
gda_sql_builder_add_id (b,
0, "publishers"),
"relationship_publisher");
gda_sql_builder_add_cond (b, 3,
GDA_SQL_OPERATOR_TYPE_EQ,
gda_sql_builder_add_id (b, 0,
"albums.publisher_id"),
gda_sql_builder_add_id (b, 0,
"relationship_publisher.publishers_id"),
0);
gda_sql_builder_select_join_targets (b, 0,
1, 2, GDA_SQL_SELECT_JOIN_LEFT, 3);

gda_sql_builder_select_add_target (b, 4,
gda_sql_builder_add_id (b,
0, "artists"),
"relationship_artists");
gda_sql_builder_add_cond (b, 5,
GDA_SQL_OPERATOR_TYPE_EQ,
gda_sql_builder_add_id (b, 0,
"albums.artist_id"),
gda_sql_builder_add_id (b, 0,
"relationship_artists.artist_id"),
0);
gda_sql_builder_select_join_targets (b, 0,
1, 4, GDA_SQL_SELECT_JOIN_LEFT, 5);

/* where condition */
gda_sql_builder_add_cond (b, 6,
GDA_SQL_OPERATOR_TYPE_EQ,
gda_sql_builder_add_id (b, 0,
"albums.album_id"),
gda_sql_builder_add_expr (b, 0, NULL,
G_TYPE_INT, 1),
0);
gda_sql_builder_set_where (b, 6);

Regards,

Vivien
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

More SqlBuilder stuff

2009-10-07T03:17:44Z

Hi Vivien!

I was trying to convert a rather complicated SQL into GdaSqlBuilder
statements but got stuck a bit:

SELECT "albums"."album_id", "albums"."name", "albums"."artist_id",
"relationship_artist"."name", "albums"."publisher_id",
"relationship_publisher"."name",
"albums"."year", "albums"."comments" FROM "albums" LEFT JOIN
"publishers" AS "relationship_publisher"
ON ("albums"."publisher_id" =
"relationship_publisher"."publishers_id")
LEFT JOIN "artists" AS "relationship_artist" ON ("albums"."artist_id" =
"relationship_artist"."artist_id") WHERE "albums"."album_id" = 1 */

I got to the point of the first LEFT JOIN rather quickly but then I have
no real idea how to continue. This is what I have so far (it's in C++, I
can convert it to C if that's easier for you):

http://de.pastebin.ca/1600971

Thanks,
Johannes

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

signature.asc (204 bytes) Download Attachment

Re: Per-table meta-data with capital letters in the table

2009-10-06T06:36:02Z

Hi!

> It does for me, see the attached file with the README to show the results I get.
>
> Can you send me a non-working example?

Sorry, I wasn't aware that it is a difference if I use a Connection or
not for the resulting SQL. I guess it's fine than.

Thanks,
Johannes

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

signature.asc (204 bytes) Download Attachment

Re: Per-table meta-data with capital letters in the table

2009-10-06T00:41:05Z

2009/10/5 Johannes Schmid <jhs@...>:
> Hi!
>
>> Id does when you use gda_sql_builder_add_id(), see for example
>> http://git.gnome.org/cgit/libgda/tree/samples/SqlBuilder/example.c.
>
> But it doesn't for set_table() for example. At least when I tried it
> didn't quote a capital table name.

It does for me, see the attached file with the README to show the results I get.

Can you send me a non-working example?

Vivien

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

SqlBuilder.tbz (3K) Download Attachment

Re: Per-table meta-data with capital letters in the table

2009-10-05T01:50:27Z

Hi!

> Id does when you use gda_sql_builder_add_id(), see for example
> http://git.gnome.org/cgit/libgda/tree/samples/SqlBuilder/example.c.

But it doesn't for set_table() for example. At least when I tried it
didn't quote a capital table name.

Regards,
Johannes

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

signature.asc (204 bytes) Download Attachment

Re: Per-table meta-data with capital letters in the table

2009-10-05T00:59:57Z

2009/10/4 Johannes Schmid <jhs@...>:

> Hi!
>
>>
>> When database providers render a GdaServerOperation to SQL when
>> performing the operation, the SQL identifiers are copied without any
>> transformation, so it's up to you to correctly set the SQL identifiers
>> values (such as table name), so the anwser is no, you don't have to.
>
> Wouldn't it be useful if GdaSqlBuilder would automatically check if the
> SQL identifiers need quoting and quote them if needed? As I programmer I
> would expect that it takes care of it as it takes care for quoting SQL
> keywords.

Id does when you use gda_sql_builder_add_id(), see for example
http://git.gnome.org/cgit/libgda/tree/samples/SqlBuilder/example.c.

Vivien
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Re: Per-table meta-data with capital letters in the table

2009-10-04T11:12:56Z

Hi!

>
> When database providers render a GdaServerOperation to SQL when
> performing the operation, the SQL identifiers are copied without any
> transformation, so it's up to you to correctly set the SQL identifiers
> values (such as table name), so the anwser is no, you don't have to.

Wouldn't it be useful if GdaSqlBuilder would automatically check if the
SQL identifiers need quoting and quote them if needed? As I programmer I
would expect that it takes care of it as it takes care for quoting SQL
keywords.

Thanks,
Johannes

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

signature.asc (204 bytes) Download Attachment

Re: Some questions/ideas about the GdaSqlBuilder API

2009-10-01T03:54:52Z

> Sounds good to me. I can do this tonight if you want.

Cool, thanks!

Johannes

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

signature.asc (204 bytes) Download Attachment

Re: Some questions/ideas about the GdaSqlBuilder API

2009-10-01T02:38:04Z

2009/10/1 Johannes Schmid <jhs@...>:

> Hi!
>
> The API is not really straight-forward to use especially because the
> method names don't give a clear indication of what happens. Murray made
> some suggestions to me:
>
> gda_sql_builder_ident => gda_sql_builder_add_id
> (Murray complained that "ident" would remind him of "identity" instead
> of "identifier")
> gda_sql_builder_expr => gda_sql_builder_add_expr
> gda_sql_builder_cond = gda_sql_builder_add_cond
> gda_sql_builder_param = gda_sql_builder_add_param
>
> IMHO that would make it clearer that something is added to the statement
> (or at least to the pool of things the SqlBuilder knows about).

Sounds good to me. I can do this tonight if you want.

Vivien
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

Some questions/ideas about the GdaSqlBuilder API

2009-10-01T02:04:59Z

Hi!

The API is not really straight-forward to use especially because the
method names don't give a clear indication of what happens. Murray made
some suggestions to me:

gda_sql_builder_ident => gda_sql_builder_add_id
(Murray complained that "ident" would remind him of "identity" instead
of "identifier")
gda_sql_builder_expr => gda_sql_builder_add_expr
gda_sql_builder_cond = gda_sql_builder_add_cond
gda_sql_builder_param = gda_sql_builder_add_param

IMHO that would make it clearer that something is added to the statement
(or at least to the pool of things the SqlBuilder knows about).

Regards,
Johannes

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

signature.asc (204 bytes) Download Attachment