Re: [gnome-db] Non datamodel queries.

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
> many rows this has an effect on. In case of UPDATE or INSERT INTO this
> function gda_connection_execute_command() returns NULL
> 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
> 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
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
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
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?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]