Re: updateable recordsets (was RE: GNOME-DB TODO)

[Rodrigo Moya <rodrigo linuxave net>]

> > About how to do it, I myself don't have a clear idea on how
> > to do it in
> > a portable way, so let's discuss about it. The only thing I
> > can think of
> > is to have the providers store a row identifier (ROWID in
> > oracle, oid in
> > postgres...), and when a field is updated, to do it through this
> > identifier. BUT, some RDBMS don't support this!
> 
> We had the discussion to not use ROWID or oid features, but
> rather to use seed tables where a 64bit integer value is
> stored per table, and every table has a field "COLNR" or the
> like where a "counter" is stored. This COLNR would be filled
> in automagically by gda when inserting a record using
> gda_recordset_insert (of course not when an explicit SQL
> INSERT statement is used).
> 
I think we should support both, giving preference to the ROWID stuff,
which is safer and cleaner if supported by the provider.

> Anyway, we would probably want to add
> 
> gda_recordset_insert
>   (creates a new row in memory, gets next COLNR from seed
>    table, but does nothing else in the backend)
> gda_recordset_delete
>   (deletes the current row from the backend by using COLNR
>    as row identifyer, i.e. creates a SQL DELETE statement
>    on the fly)
> gda_recordset_post
>   (writes the current row back to the backend by using COLNR
>    as row identifyer, i.e. creates a SQL INSERT or SQL
>    UPDATE statement on the fly)
> 
> to the client api.
>
this looks better than the current method definition in the IDL files.
In fact, I don't understand exactly the idea Michael (the founder of
gnome-db) had when doing this. I'll have a look at it.

> We would also need some means to change gda_field values.
> 
yes, that's easy. And I'll take advantage to continue with the code
cleanup I started in the gda-client lib.

> As a result of this, you would only have to build the SQL
> SELECT statement, not the others.
> 
> There have also been thoughts about completely abstracting
> gda access from SQL and somehow write a function like
> 
> gda_recordset_open_fieldlist (char *table, char **fieldlist);
> 
> but you really got us in the midst of our thoughts, so if
> you can wait a few more days, I will (probably over the
> weekend) prepare some written proposal on this.
>
well, what you say makes sense, but I think we should use SQL when
supported, and if not, send a XML query, whose purpose is this
precisely.