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

[Rodrigo Moya <rodrigo gnome-db org>]

On Thu, 2005-01-06 at 21:44 +1000, Bas Driessen 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.
>
yes, but accessing rows by number will be wrong, if I understood
correctly. That is, you remove row 8, and then client requests the new
row 8 (which was row 9). In the way the provider is done, it seems it's
going to fail for some cases, unless you add a lot of code to detect the
correct numbering.

>  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?
> 
I am thinking that the provider should probably have rows in a dynamic
array, and for rows it hasn't retrieved yet, have a flag that indicates
the row needs to be retrieved. Thus, when you remove a row, you only
need to remove it from the array and all rows will be renumbered
correctly. Similarly, when getting the rowcount from PostgreSQL, the
provider should just add empty records (with the 'needs-retrieveing'
flag set to on) for all rows.

Or we could change GdaDataModelArrayHash to be more clever about the row
numbers. That would probably be much better, thus the postgres provider
just needs to call a gda_data_model_array_hash_remove_row function.

> Also any tips/advise how to deliver patches (ie  which diff command
> from where) to this list are appreciated.
> 
I use this: cvs -z3 diff -up

which includes the function names in the patch.
-- 
Rodrigo Moya <rodrigo gnome-db org>