Re: [gnome-db] Will you deprecate GdaDataModelQuery? and other questions

["Daniel Espinosa" <esodan gmail com>]

2008/2/11, Daniel Espinosa <esodan gmail com>:
> 2008/2/9, Vivien Malerba <vmalerba gmail com>:
> > On Feb 9, 2008 11:49 AM, Daniel Espinosa <esodan gmail com> wrote:
> > > 1. I found that you plan to deprecate GdaQuery on libgda 3.2/4.0, but
> > > GdaDataModelQuery needs a GdaQuery to create a new one, then may be is
> > > better to deprecate
> >
> > GdaQuery is replaced by another object (GdaStatement) which will be
> > used as a replacelement in the
> > GdaDataModelQuery object.
> >
> > >
> > > gda_data_model_query_new (GdaQuery *query)
> > >
> > > to have:
> > >
> > > gda_data_model_query_new (GdaDataModel *model)
> > >
> > > and leave GdaDataModelQuery Object to use GdaQuery internaly.
> > >
> > >
> > > 2. In 4.0 and/or 3.2 witch will be the procedure to INSERT, UPDATE,
> > > DELETE rows in database?
> >
> > Same as 3.0: use a GdaDataModelQuery or directly run SQL statements
> >
>
> OK.
>
> > >
> > > By now I think you need From a GdaQuery (deprecated) get a
> > > GdaDataModel, create a GdaDataModelQuery (autocalculate the required
> > > GdaQuery) and then (optionaly) use a GdaDataModelProxy to do it.
> > >
> > > For the new 4.0 and/or 3.2, i think you could:
> > >
> > > >From the GdaDictTable get a GdaDataModel (representing a
> > > GdaDataModelQuery with the autocalculated GdaQuery internaly and all
> > > the data in the table), then use a GdaDataModelProxy (optionaly) to
> > > modify the data in the database. I think this will be the simpliest
> > > way to use GDA.
> >
> > This sort of mechanism will be implemented in the data models returned
> > by the providers.
> >
>
> Then  in 3.2/4.0 will all returned data models be modificable?
>
> > >
> > > If you agree I can create the funcition in GdaDictTable to do the last
> > > one, and then deprecate GdaDataModelQuery.
> > >
> > >
> >
> > GdaDict and related objects will also be removed.
> >
> > I've just committed the first compiling version in the V4 brench, if
> > you want to test it.
> >
>
> I'm already working with 4.0 branch and sended some patches for bug
> #508407 (for 3.1, but could be  ported to 4.0).
>
> I'm working in a new object to manage data rows in the database with a
> simple API:
>
> data_object_new ---> Get a new object reference using a row_id in a
> datamodel or GValue ID
> data_object_add_new --> Appends a new row
> data_object_get_value --> Get a value from the column using its name.
> data_object_set_value --->Modify the value at a column using its name
> data_object_delete ---> Deletes the row
> data_object_update ----> Saves all modifications to the row managed by
> this object
>
> The object's parent is  GdaDataModelProxy to store temporaly the
> modifications, but allows the user to use an object that is getted
> directly from the DB and modified too.
>
> Now I'm creating some specialiced objects, that use this object as
> parent to update/modify itself and do some other task like search in
> the database in other tables rows that actualy uses its ID as a
> reference  - i. e. if this object (an account) has registers
> associated to it calling a SQLstat
>


Sorry was a misstake, now I continue:

And I want to know if you're interested to include such object.

This object just work for a row at a time, and it's specialiced object
from GdaDataModelProxy.

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