Re: [gnome-db] Non datamodel queries.

["Vivien Malerba" <vmalerba gmail com>]

On 9/6/06, Bas Driessen <bas driessen xobas com> wrote:
>  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.

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?