Re: [gnome-db] patch : gda-postgres remove-row.

[Vivien Malerba <vmalerba gmail com>]

On Fri, 07 Jan 2005 11:20:28 +1000, Bas Driessen <bas driessen xobas com> wrote:
> On Thu, 2005-01-06 at 15:36 +0100, Vivien Malerba wrote:
> > On Thu, 06 Jan 2005 21:44:44 +1000, Bas Driessen <bas driessen xobas com> wrote:
> > >  Hello,
> > >
> > >  I am (re)visiting the record-set implementation again for the Postgres
> > > provider, since I want to start using that now. Let's start with the
> > > non-existing "remove-row" method.
> > >
> > >  Attached a patch for the "remove-row" method for data models for the
> > > Postgres provider. It will update both the data model as the underlying
> > > database. Some comments:
> > >
> > > 
> ..
> ..
> 
> > I've looked at the patch and it looks ok for me, except for the row
> > flagged as "R" which in fact remains in the data model (which means
> > other function on the data model will retyurn wrong results).
> 
> The row-id should not be confused with the row-number. Row-number
> (gda_row_get_number) contains the number of the row in a data model and
> I do not touch that, while row-id (gda_row_get_id) contains any
> additional identifier. This field is not used until now in libgda itself
> (besides being set by the postgres provider), so we may as well start
> using it.
> 
> Also, do I need to trigger a "gda_data_model_changed" or/and
> "gda_data_model_row_removed"?

If you call gda_data_model_row_removed(), then the "row_removed"
signal is emitted, and then the "changed" signal is also emitted.

> 
> 
> > Maybe the easiest solution would be to make sure the "R" flagged rows
> > are not accounted anywhere.
> >
> 
> Sure, I don't mind how it is implemented, as long as I can identify a
> row as being "removed". If you still think I should not set the "R" flag
> using the gda_row_set_id, can you please elaborate a bit more on how I

Using the "R" flag is OK for me!

> can make sure that "R" flagged rows are not accounted anywhere?

Yes.

> 
> 
> > However, if you feel like making something more general, there is a
> > feature I'd like to have: it's the possibility to cut a GdaDataModel
> > into chuncks: for example being able to have no more than 100 rows in
> > a data model at a time (if the data coming from the SELECT query
> > returned more than 100 rows), and then ask to have the
> > first/next/previous/last chunck of 100 rows. I have made some
> > modifications to the GdaDataModel which I want to commit first before
> > you start doing modifications on the GdaDataModel (I'll do it ASAP).
> >
> 
> What would be the benefit of this? At the moment, when using the hash
> version of the data model, only rows requested will be placed in the
> data model. So even if the query contains > 100 entries, if the user
> (developer), selects row 10-20, only those will be in the data model. On
> the other hand, once data is in the data model, it will stay there until
> the model is released. So it will only grow, which can have a negative
> effect on performance. So the reason you want this is for performance
> reasons only? Did you test/do you know it will have a dramatic positive
> impact?

I have not made any test but I assume that transfering less data from
the DBMS backend is better if we don't need that data. I'm thinkning
of this feature because I'm working on libgnomedb and I have the
problem of how to present in a GUI the data stored in a GdaDataModel
using chuncks (having thousands of rows in a GUI is bad for
performances and for GUI design).

> 
> Also how would "append" work then for instance. When using append-row, a
> row is added to the data model, that does not exist in the Postgres
> cursor for instance. So if the user after the append, ask for the
> previous 100 chunck, the chunck that contains the appended records will
> be freed and lost. So if the user switches back to the last 100 chunck,
> the update is no longer in the data model, while it has been updated in
> the table.

You're right, I need to think more about this... Maybe it's better if
the "chuncking" is implemented on top of a GdaDataModel as a filter.


> Well, there is an append and update already. It would be logical to have
> the remove as well to be complete. For the time being I can ship my own
> patched version of libgda, but as long as I know that the solution
> is/will be accepted. Otherwise I will start building code around
> features that will never make it into the product.
> 
> 

I just meant that before the patch can be applied, it must be complete
to avoid having some gda_data_model_ functions returnig wrong results
when a row has been removed. If you can make sure that the "R" rows
are correctly handled in other functions (like the row count
function), then I'll be happy to apply the patch.

Thanks,

Vivien