On 9/6/06, Bas Driessen <[EMAIL PROTECTED]> wrote: > > On Tue, 2006-09-05 at 16:03 +0200, Vivien Malerba wrote: > > On 9/5/06, Bas Driessen <[EMAIL PROTECTED]> wrote: > > > > Hello, > > > > If I trigger a command like UPDATE or INSERT INTO using function > > gda_connection_execute_command(), I would like to know > how > > many rows this has an effect on. In case of UPDATE or INSERT INTO this > > function gda_connection_execute_command() returns NULL > and > > therefore not useful. Then I had a look at function > > gda_connection_execute_command_l(), but also here NULL is > > returned if the result of a query is not a list of data. > > > > I did look up the source of the old function > > gda_connection_execute_non_query() function (which was > > perfect to have btw), but if I use similar logic now, I just can't get the > > number of affected rows back. > > > > So how can I execute an UPDATE or INSERT INTO command and get the number > of > > affected/inserted rows back with the current API? > > You're right, I did not think of that! I believe the API needs to be > improved to return that information. At the moment such information > returns as a textual comment (a GdaConnectionEvent) from some > providers, but there is nothing formalized. > > I see 2 possibilities: > - either the GdaServerProvider->execute_command() can > return a list of > GdaDataModel (for SELECT queries) mixed with GdaParameter (for UPDATE, > INSERT and DELETE to contain the number of rows imoacted by the query) > and the caller has to parse the list and handle each item depending on > the type of object in the list > - or add a return parameter to > GdaServerProvider->execute_command() > and modify the API > > I'd prefer the 1st solution. > > What do you think? > > > Well, the easiest for an programmer-user of libgda would be situation. > However, this solution may be limited perhaps. I mean what would be returned > if the a user issue a CREATE TABLE statement for instance as a "non"-query? > > I am happy with either solution, as long as the number of affected rows can > be retrieved somewhere, without too much programming. Perhaps a combination? > Implement situation 1 and create an additional API call which essentially is > a kind of wrapper to easily extract the value. >
The more I think about it, the more I'm convinced that solution 1 is the best. For example in the following situations: 1) the query is a SELECT query => nothing changes and a GdaDataModel is returned in the list 2) the query is UPDATE/DELETE/INSERT => instead of not returning anything, the provider returns a GdaParameterList containing a gint parameter named "impacted_rows" (or similar) giving the number of rows impacted 3) the query is CREATE TABLE => instead of not returning anything, the provider returns a GdaParameterList containing a GObject parameter named "event" which is a GdaConnectionEvent (notice) object having a GDA_CONNECTION_EVENT_CODE_TABLE_CREATED (which does not yet exist) and the name of the created table as description. 4) the query is BEGIN, and the result is similar to 3) except that the event code is GDA_CONNECTION_EVENT_CODE_TRANSACTION_BEGIN 5) etc... Also because we return a GdaParameterList object, in the furure that object can contain more than one parameter (so we can return more information such as elapsed time, query plan, etc) which make this mechanism extensible. Of course the higher API can be improved to use this new low leven feature. What do you think? _______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
