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

[Vivien Malerba <vmalerba gmail com>]

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:
>  
>  - Only works if there is a unique key available (similar like the existing
> "update-row" method). This is probably correct, but I am not sure if
> Postgres has a concept of a "row-id" that we can use. 
>  
>  - Postgres provider uses the hash version of a Data Model. This means that
> only information requested will be in the Data Model. If a row is requested
> from the data model that has not been loaded yet, the information will come
> from the Postgres cursor (PGresult). Because of this concept, it is pretty
> much impossible to physically remove a row from the data model, since the
> numbering of the data model will then no longer be in sync with the Postgres
> cursor (data can not be removed from the Postgres cursor unless triggering
> the SQL again which can be time consuming). Therefore I came up with the
> concept of placing the text "NULL" in all fields of the row deleted from the
> data model and setting the row id (gda_row_set_id) to "R" (for Removed). 
> This way deleted rows can easily be identified without destroying the
> current structure. Perhaps we need a setting "visible" for rows in a data
> model? The only thing that is debatable then is the number of rows in a data
> model. It should return with the number of rows minus deleted ones, but if
> we do that then chances are not all rows are processed that should be
> processed. Better to skip row by testing on the id (gda_row_get_id). A 2nd
> type of row return perhaps? Suggestions?
>  
>  Please let me know if this implementation is acceptable. If not, let's
> discuss / advise how it otherwise should work.
>  
>  Also any tips/advise how to deliver patches (ie  which diff command from
> where) to this list are appreciated.

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).

Maybe the easiest solution would be to make sure the "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).

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.

Thanks,

Vivien