Re: [gnome-db] GdaColumn as a GObject

[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?

> -> 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?

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com