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

[Reinhard Mueller <rmueller1 vanenburg com>]

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

As I read this now again, I see that is crap.
It should of course be ROWNR, not COLNR.

> > 
> 
> As This feature should be implemented by the provider itself, 
> why not allow it
> to decide to use either the seed tables or the oids (as 
> example Postgres has the
> oid system and so the recordset feature system would be 
> available to every DB
> regardless of its structure). For DBMS which do not support 
> oids or the like,
> then the seeds tables could be used. 
> What do you think?

I'm not quite sure if the feature should always be implemented
by the provider. IMHO it would be best to let the provider
implement it for non-SQL-databases (to avoid double
translation) but to have it implemented on the client-side
for SQL-databases, as it would be the same code for all.
But, as said above, I'm not sure about that.

If we implement it in the providers, using oids is ok for
being able to update specific recordsets.

But if we generally used seed tables, the ROWNR could also
serve as the primary key of the table.
On the other hand we might say that having primary keys is
a question of data design and should not be covered by GDA.

Reinhard