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

[Vivien Malerba <malerba linuxave net>]

----------  Forwarded Message  ----------
Subject: Re: updateable recordsets (was RE: GNOME-DB TODO)
Date: Thu, 20 Jul 2000 10:19:17 +0200
From: Vivien Malerba <malerba@linuxave.net>


On jeu, 20 jui 2000, you wrote:

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

If I understand this means the database must have a special tables, and every
table must include a special field, which means the GDA layer need the DB to
have a special structure. 
So, either the DB has this required structure and the
recordset replacement can be done, or it has not and the replacement feature
will not be available (of course we could make a script to modify the structure
of a non compliant DB to make it compliant). Am I right?

> 
> Using seed tables would have some advantages:
> * you can use them partably in any database, even in CSV files
> * the row identifyer would have the same type in every DB,
>   which makes coding much easier
> * the row identifyer is available even before the record
>   is posted to the backend, which can ease many tasks in
>   creating master-detail related records
> 
> 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.
> We would also need some means to change gda_field values.
> 
> 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);
>

Or use the XML queries.
 
Cheers,

Vivien
-------------------------------------------------------