Re: [gnome-db] GdaColumn as a GObject

[Vivien Malerba <vmalerba gmail com>]

2005/9/26, Murray Cumming <murrayc murrayc com>:
> On Sun, 2005-09-25 at 15:59 +0200, Vivien Malerba wrote:
> > 2005/9/23, Murray Cumming <murrayc murrayc com>:
> > > On Thu, 2005-09-22 at 21:53 +0200, Vivien Malerba wrote:
> > > > 2005/9/22, Murray Cumming <murrayc murrayc com>:
> > > > > In libgda HEAD, GdaColumn was recently changed to be a GObject, instead
> > > > > of being a copyable boxed type (struct).
> > > > >
> > > > > This makes ownership a little less obvious. For instance, may we ever
> > > > > use the gda_column_set_*() methods on a GdaColumn that we get from
> > > > > gda_data_model_describe_column() before passing it to
> > > > > gda_data_model_append_column()? I guess not, because we are using the
> > > > > same instance.
> > > > >
> > > > > I guess we need to always create a new GdaColumn before using the set
> > > > > methods, but it seems worth asking/clarifying.
> > > > >
> > > > > If we could keep the copy function (removed when it was changed to a
> > > > > GObject), some things would be easier for me.
> > > >
> > > > You're right about that problem, I had not seen it!
> > > >
> > > > However it seems that method is not implemented by any of the
> > > > GdaDataModel* objects, so there are two possibilities there:
> > > > -> change the API to something like
> > > > GdaColumn *gda_data_model_append_column (GdaDataModel *model); or
> > > > -> remore that method completely.
> > >
> > > append_column() was just an example chosen at random. I'd guess that it
> > > affects other uses of this object.
> > >
> > > But with
> > > GdaColumn *gda_data_model_append_column (GdaDataModel *model)
> > > do you mean that we should then use the gda_column_set() after it has been
> > > appended? Surely we can't do that at any time, because the actual
> > > database structure is only changed at certain times.
> > >
> > > > I'd vote for the second solution because:
> > > > -> data models are like tables and the number of columns is known when
> > > > the object is created (like for the GtkListStore and GtkTreeStore
> > > > models)
> > > > -> obviously it has not been used much (otherwise people would have
> > > > noticed that it was not implemented) and it's always better to have
> > > > simple and concise API.
> > > >
> > > > Tell me what you think and I'll do the changes before 2.0.
> > >
> > > I'd prefer that
> > > - the copy() and equals() methods were re-added.
> > > - Documentation (and use of const) would show whether a copy would be
> > > taken. For instance,
> > >
> > > /** yadda yadda
> > >  * @column The description of the new column. This column object will be
> > > copied.
> > >  */
> > > void gda_data_model_append_column (GdaDataModel *model, const GdaColumn*
> > > column)
> > >
> > > though that's not completely unambiguous.
> > >
> > > But I don't know the reasons for changing it to a GObject in the first
> > > place. GObjects are usually for things that you _want_ to share via a
> > > reference.
> > >
> >
> > GObject can also have properties, emit signals which can be usefull to
> > ensure data integrity.
> >
> > I've just commited new versions of the GdaDataModel, GdaRow and
> > GdaColumn which make the API simple and easy to understand.
>
> Thanks. I'll take a look tomorrow.
>
> > Just a few axamples:
> > -> if a user wants to modify a value in a data model, all is required
> > is get a GdaRow pointer with gda_data_model_get_row() and use
> > gda_row_set_value() to change the value.
> > -> if a user wants to add a row, just create a new GdaRow object using
> > gda_row_new(), call gda_data_model_append_row() and then
> > g_object_unref (row).
> > -> if a user wants to add a column, call
> > gda_data_model_append_column() and the set the properties of the
> > returned GdaColumn.
>
> When do these changed properties actually take effect? Is every change
> made immediately to the database, or do we need to call some update
> method?

Normally the changes should occur in the GdaDataModel as soon as the
call to any of these function returns; the return value of each of the
modification functions (either on a row or on a model) indicates
success or failure. In the next version of libgda I plan to add a
GError ** argument to these functions to make a correct error
reporting.

>
> > -> if a user wants to update a complete row, create a new GdaRow
> > object or copy an existing one, call gda_data_model_update_row() and
> > then g_object_unref (row)
>
> Great.
>
> Still, may I have the copy and equals methods back, so I can use
> GdaColumn as a way to store field attributes separately? Or would that
> be too complicated to support?
>

I've kept gda_row_copy() and writing gda_row_equals() should be very easy.

Cheers,

Vivien