Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.php > #16800

Re: Closing a statement causes a "malformed object" error on theresult - by design ?

From "Christoph M. Becker" <cmbecker69@arcor.de>
Newsgroups comp.lang.php
Subject Re: Closing a statement causes a "malformed object" error on theresult - by design ?
Date 2016-06-27 13:10 +0200
Organization solani.org
Message-ID <nkr1i3$av4$1@solani.org> (permalink)
References <576fede9$0$5918$e4fe514c@news.xs4all.nl> <nkponn$fii$1@solani.org> <5770f4f5$1$5918$e4fe514c@news.xs4all.nl>

Show all headers | View raw


On 27.06.2016 at 11:44, R.Wieser wrote:

> Christoph M. Becker <cmbecker69@arcor.de> schreef in berichtnieuws
> nkponn$fii$1@solani.org...
>
>> I presume you mean something like: [snip]
> 
> Something like that, but instead of INSERTing I was SELECTing data. […]

I was also SELECTing; the INSERT was only to have something to select.
:)  See <https://3v4l.org/AYuI3>.

>> I don't think it's a bug, but the behavior should be
>> explicitly mentioned in the manual,
> 
> :-) Which is pretty-much what my question was all about: Is someone aware of
> this behaviour, and if so knows what its origin is.

The behavior stems from the fact that when SQLite3Result::fetchArray()
is called, it is first checked whether the related stmt_obj is
initialised[1].  When SQLite3Stmt::close() is called, the stmt_obj is,
however, destroyed[2], so the warning is raised[3].

Of course, it would be possible to check for existing results, and to
not close the statement when ::close() is called (maybe raising a
notice/warning) in this case, but that would require the programmer to
call SQLite3Result::finalize() before calling SQLite3Stmt::close(), what
appears to be too tedious.

It might have been best not to offer SQLite3Stmt::close() in the first
place, and simply close the statement when the statement object will be
destroyed (as it's done by PDO), but removing the close() method now
would cause major BC issues, so that doesn't appear to be an option.

>> so I suggest to file a doc bug against <https://bugs.php.net/.
> 
> I'm currently not even sure if it is in fact a bug.

I didn't suggest that this is a bug, but rather a *doc* bug, i.e.
something important that the documentation is missing.  It might be
arguable that the warning message is a real bug, or at least could be
improved, but that appears to be secondary, if the documentation already
would state that a statement must not be closed, if further operations
on any of its results will be executed.

> I would not want to play the role of a first-best noob who, because he
> doesn't understand how something is designed to work and is not aware of the
> relevant documentation, declares its to be one and thereby wastes the time
> of those bug-list maintainers ... :-( :-)

Understandable. :)  I've filed a ticket myself:
<https://bugs.php.net/72502>.

[1]
<https://github.com/php/php-src/blob/php-7.0.8/ext/sqlite3/sqlite3.c#L1753>
[2]
<https://github.com/php/php-src/blob/php-7.0.8/ext/sqlite3/sqlite3.c#L1286>
[3]
<https://github.com/php/php-src/blob/php-7.0.8/ext/sqlite3/sqlite3.c#L68-L72>

-- 
Christoph M. Becker

Back to comp.lang.php | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Closing a statement causes a "malformed object" error on the result - by design ? "R.Wieser" <address@not.available> - 2016-06-26 17:02 +0200
  Re: Closing a statement causes a "malformed object" error on the result - by design ? Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-26 12:23 -0400
    Re: Closing a statement causes a "malformed object" error on theresult - by design ? "R.Wieser" <address@not.available> - 2016-06-26 22:07 +0200
      Re: Closing a statement causes a "malformed object" error on theresult - by design ? Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-26 16:45 -0400
        Re: Closing a statement causes a "malformed object" error ontheresult - by design ? "R.Wieser" <address@not.available> - 2016-06-27 12:26 +0200
          Re: Closing a statement causes a "malformed object" error ontheresult - by design ? Jerry Stuckle <jstucklex@attglobal.net> - 2016-06-27 10:11 -0400
      Re: Closing a statement causes a "malformed object" error on theresult - by design ? "Peter H. Coffin" <hellsop@ninehells.com> - 2016-06-26 15:55 -0500
        Re: Closing a statement causes a "malformed object" error ontheresult - by design ? "R.Wieser" <address@not.available> - 2016-06-27 11:11 +0200
  Re: Closing a statement causes a "malformed object" error on the result - by design ? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-06-27 01:33 +0200
    Re: Closing a statement causes a "malformed object" error on theresult - by design ? "R.Wieser" <address@not.available> - 2016-06-27 11:44 +0200
      Re: Closing a statement causes a "malformed object" error on theresult - by design ? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-06-27 13:10 +0200
        Re: Closing a statement causes a "malformed object" error ontheresult - by design ? "R.Wieser" <address@not.available> - 2016-06-27 15:02 +0200
          Re: Closing a statement causes a "malformed object" error ontheresult - by design ? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-06-27 15:33 +0200
            Re: Closing a statement causes a "malformed object" error on the result - by design ? "R.Wieser" <address@not.available> - 2016-06-27 16:45 +0200
              Re: Closing a statement causes a "malformed object" error on the result - by design ? "R.Wieser" <address@not.available> - 2016-06-28 12:45 +0200
                Re: Closing a statement causes a "malformed object" error on the result - by design ? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-06-28 15:25 +0200
                Re: Closing a statement causes a "malformed object" error on theresult - by design ? "R.Wieser" <address@not.available> - 2016-06-28 18:41 +0200
                Re: Closing a statement causes a "malformed object" error on theresult - by design ? "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-06-28 19:29 +0200

csiph-web