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

[Rodrigo Moya <rodrigo linuxave net>]

> > 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.
> 
Right! this is what I also think. If using seed tables, the
INSERT/UPDATE command can be completely manager by the gda-server lib.
If using OIDs, a call is made to the provider's specific
gda_connection_insert function.

> >
> > 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.
>
yes, please, the XML query idea is IMO a very very great thing, so
please let's have it in mind! On the web site you can find the proposal.
And I don't mind at all having them removed from GDA and moved to
elsewhere (GNU Enterprise...), and maybe just leaving in GDA the
GDA-specific parts.
 
> > 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).
> 
yes, you're right, but I don't see the pain in maybe having an option to
disable this feature if it's not desired to allow to have this.