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

[Bas Driessen <bas driessen xobas com>]

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


> 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
can make sure that "R" flagged rows are not accounted anywhere?


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

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. 

Maybe I interpret this "chuncking" wrong. If there are any specs of it
somewhere, let me know.

> I don't know how better to solve the problem (I don't know all that
> much libgda's internals), but I prefer to have it solved before
> committing the patch.
> 

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.