Re: [gnome-db] Non datamodel queries.

[Bas Driessen <bas driessen xobas com>]

On Wed, 2006-09-06 at 08:38 +0200, Vivien Malerba wrote:
> 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?

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.