On 9/6/06, Bas Driessen <[EMAIL PROTECTED]> wrote: > > On Wed, 2006-09-06 at 08:38 +0200, Vivien Malerba wrote: > > 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? > > > Sounds good to me. The only thing that is confusing is that depending on > the input, different type of output is returned. DataModel for situation 1 > and GdaParameterList for situation 2 etc. How can we see the difference of > what is returned? Do we need to indicate that as well, or just test result > like if GDA_DATA_MODEL etc (sorry don't have the exact syntax at the moment, > but you understand what I mean) than do this, otherwise that.
Yes, I think one can test each object in the returned list with GDA_IS_DATA_MODEL(), or GDA_IS_PARAMETER_LIST(). I'll do the modifications ASAP. Cheers, Vivien _______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
