List:MySQL++« Previous MessageNext Message »
From:Jose Mortensen Date:September 29 2004 4:31pm
Subject:RE: query.store, query.exec might yield in segmentation fault
View as plain text  
I think you guys are missing the point of my post. There is no need for an
sql parser, mysql already has it. So why write another one.

Mysql C api function mysql_store_result() has the correct functionality, it
returns null when the query does not return a result, there is a malloc
error or when there is an error in the connection.

MySql++ is a wrapper around MySql C, so it calls mysql_store_result() but
instead of checking if the function returned a null, it tries to use the
result which ends up in a segmentation fault. That is the problem, and that
is what the patch I submitted was all about (see msg# 3522).


> Just use execute when nothing will be returned and store when a result set
is returned.
> Put the statement within a try/catch block and handle whatever comes
back - including a
> null result set. Isn't this just good programming style?
>
> Jo Ellen

Now Jo Ellen, That is exactly my problem. My code is forwarding an unknown
sql query to the database, so I can not choose between exec or store because
I don't know what kind of query it is. As Warren pointed out I should write
an sql parser, which I did and it just adds un-needed complexity to the
situation. It is a lot easier to use mysql_store_result() and check for null
which has to be done anyways as explained above.

An again, the problem is that a try/catch will not catch anything since no
exception is thrown in this case, it produces a segmentation fault. So, this
good programming style can not be applied for my problem. (plus, I don't
know if the query returns something and I don't wanna know. I will just
forward the answer back if any).


Not a complain, just my 2 cents for the C++ api

Jose




-----Original Message-----
From: Jose Mortensen [mailto:jose@stripped]
Sent: Thursday, September 23, 2004 6:07 PM
To: plusplus@stripped
Subject: query.store, query.exec might yield in segmentation fault


Some code like this

query << "drop table mytable";
Result res = query.store();
if (res.is_empty()) {
    do something ... or don't do something ...
}

Produces a segmentation fault at res.is_empty(). I think it should either
throw an exception or return a empty Result.

I know it should use exec instead, but:

1. C++ code should never produce a segmentation fault. Should produce at
most an exception.

2. In some cases like, for example, a user console program where the query
is user defined, it is difficult to predict if the query should return
something or not. In cases like that better to return an empty result. I
think.


 In the opposite case, where a select is used with exec, it will yield in a
out of sync exception that can not been recovered in future query.store
functions unless the connection to the database is closed.


My preference is to return an empty result.

Thread
query.store, query.exec might yield in segmentation faultJose Mortensen24 Sep
  • Re: query.store, query.exec might yield in segmentation faultWarren Young24 Sep
  • RE: query.store, query.exec might yield in segmentation faultJose Mortensen29 Sep
Re: query.store, query.exec might yield in segmentation faultWarren Young24 Sep
RE: query.store, query.exec might yield in segmentation faultJo Ellen Brandmeyer24 Sep