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



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).
> 
> As I read this now again, I see that is crap.
> It should of course be ROWNR, not COLNR.
> 

Right!


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

Why not? The provider side is now a common lib to all the providers, namely
gda-srv, and some code specific to the DBMS. Why not keep that organization?
I mean the server side of the functions like gda_recordset_insert(), etc could
be implemented completely in the gda-srv part if the DB has the seed tables
structure, or in the gda-srv and DBMS specific part if the DBMS has oids and
the DB does not have the seed tables structure.

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

Well, if the query is given as an XML query, ALL the recordsets can be updated
because the structure of the query can be analysed. One more reason to use XML
queries.

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

I don't think GDA should impose a database structure, it sould just be an
option (so recordset update should remain an option).




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]