Re: [gnome-db] Non datamodel queries.

[Bas Driessen <bas driessen xobas com>]

On Tue, 2006-09-05 at 16:03 +0200, Vivien Malerba wrote:
> On 9/5/06, Bas Driessen <bas driessen xobas com> 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.

Bas.