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

Groups > comp.lang.php > #16806

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

Show all headers | View raw

On 28.06.2016 at 12:45, R.Wieser wrote:

> I just took a look at the sourcecode of PHP 5.4.29 (last one available for
> XP), and noticed the below in the SQLite3Result::fetchArray method:
> 
> […]
> 
> In short, it generates an error citing the result object as the source/cause
> when the statement object appears not to be initialized, which is a WTF in
> itself.  But it also throws the very same error when the statement object is
> not actually present (has been closed), which another WTF altogether. :-\

I have to admit that this behavior is somewhat strange.  On the other
hand, would the following message be really more helpful:

| Warning: SQLite3Result::fetchArray(): The SQLite3Stmt object has
| not been correctly initialised

Maybe a bit.

> Hmmm ... I wanted to make a remark about the above check being present in
> this method too, making it impossible for the result object to be destroyed
> when the statement object has been closed before it, but looking further
> down the code I realized that the result object, when its generated(?) by a
> prepared statement, isn't destroyed, cleared or done anything else with
> anyway. :-o :-)

I assume that the developers did that as a deliberate design decision,
because destroying the result object can be done when the prepared
statement object is destroyed, so that it could be reused for the same
prepared statement, if necessary.

> Well, this (no dependancy handling) explains why I couldn't get any results
> when I told the statement object I didn't need it anymore, as well as
> showing that the result object is very dependant on the statement object
> itself -- It doesn't actually do anything itself, but defers everything to
> the statement object.

That appears to be a reasonable design decision, because the sqlite3
library doesn't have any form of result object; instead everything (e.g.
fetching the next row, querying columns, etc.) is done on sqlite3_stmt
objects (thus, the strong coupling between SQLite3Stmt and
SQLite3Result).  Neither does PDO, by the way.

> Oh well, I just need to rember that in PHP I need to (keep) track (of)
> object dependancies myself I guess. :-\

No, at least not generally.  The Zend engine does track object
dependencies wrt. automatic memory management.  Most (if not all)
extensions do rely on that, and that usually works fine (besides some
known issues wrt. cyclic references, which are tolerated for performance
reasons).

From what I can tell (it's getting rather tricky there), the sqlite3
extension also relies on the Zend engine's memory management; of course,
there might be bugs in this regard, but the extension has a pretty fair
code coverage[1], and at least sometimes the tests are supposed to be
run with valgrind enabled, which would report any memory leaks.

[1] <http://gcov.php.net/PHP_5_6/lcov_html/ext/sqlite3/sqlite3.c.gcov.php>

-- 
Christoph M. Becker

Back to comp.lang.php | Previous | Next — Previous 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