maria-developers team mailing list archive

[Alexey Botchkov <holyfoot@xxxxxxxxxxxx>]

Sergei,

> SERVER_STATUS_CURSOR_EXISTS. Why is it not returned for 'reading
> metadata'? Where does the client skip it?

The server status is sent to the client twice - with the recordset
metadata and then with the resulting recordset.

You can see it in the JOIN::exec()
First we do result->send_result_set_metadata(). At this point the server_status
isn't set yet to the SERVER_STATUS_CURSOR_EXISTS. So the server status sent to the
client along with the metadata is correct.

Then we call do_select(), were we internally run the SP, which sets the
SERVER_STATUS_CURSOR_EXISTS status. So it's sent to the client with the
resulting recordset only.

Best regards.
HF


31.03.2014 7:33, Sergei Golubchik wrote:
> Hi, Alexey!
>
> On Mar 27, Alexey Botchkov wrote:
> > Hi, Sergei.
> >
> > > Why does embedded fail while a normal client-server protocol is ok with
> > > that?
> > The difference is that the client checks the server status twice during
> > execution
> > - after the metadata reading and after the actual data.
> > That SERVER_STATUS_CURSOR_EXISTS is returned on the 'reading data' stage
> > and the usual client just skips it. But for the embedded server
> > that status is same in both cases. And the 'reading metadata' part
> > crashes when it sees that server status.
> > It's in the prepare_to_fetch_result() called from mysql_stmt_execute().
> Yes, I see that prepare_to_fetch_result() checks for
> SERVER_STATUS_CURSOR_EXISTS. Why is it not returned for 'reading
> metadata'? Where does the client skip it?
>
> > I see no reason to store both statuses for the embedded server just to
> > imitate
> > the usual client's behaviour. It's better not to return the misleading
> > status in this case.
> I agree about not returning the misleading status, but I'd still like to
> understand why the regular client works.
>
> Regards,
> Sergei