php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #44287 mysql_fetch_object calls __construct too late
Submitted: 2008-02-28 22:17 UTC Modified: 2011-01-31 12:46 UTC
Votes:5
Avg. Score:4.6 ± 0.5
Reproduced:4 of 4 (100.0%)
Same Version:4 (100.0%)
Same OS:4 (100.0%)
From: jaap dot taal at gmail dot com Assigned: mysql (profile)
Status: Wont fix Package: MySQL related
PHP Version: Any OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
27 - 16 = ?
Subscribe to this entry?

 
 [2008-02-28 22:17 UTC] jaap dot taal at gmail dot com
Description:
------------
I'm using the mysql_fetch_object's ability to create a custom object. The constructor of the object initializes the .
The scripts simply gets all the data from the a table and uses mysql_fetch_object to create the objects. The id property however is not set, it is null.
I think that the mysql_fetch_object function first creates an object setting properties and than it turns this object into an object of the specified type, calling the constructor in the proces.

looking at the php source for mysql_fetch_object shows me that a hash is retrieved first: php_mysql_fetch_hash
After that the hash is converted into an object: object_and_properties_init

I think an object should be created calling its constructor and than after that is done, the properties should be set.

Reproduce code:
---------------
<?php
/*
   USE test;
   DROP TABLE IF EXISTS `tbl_content`;
   CREATE TABLE `tbl_content` (
   `id` int(11) NOT NULL auto_increment,
   `content` text,
   PRIMARY KEY  (`id`)
   ) ENGINE=MyISAM DEFAULT CHARSET=latin1;
   INSERT INTO `tbl_content` VALUES (1,'asdf1'),(2,'asdf2'),(3,'asdf3');
 */
$link = mysql_connect('localhost', 'test', 'test');
mysql_select_db('test');
class tbl_content {
  var $id;
  var $content;
  function tbl_content() {
    $this->id = null;
  }
}
$result = mysql_query("SELECT * FROM tbl_content", $link);
if (!$result) {
  die(mysql_error());
}
while ($obj = mysql_fetch_object($result, 'tbl_content')) {
  var_dump($obj);
}
?>


Expected result:
----------------
object(tbl_content)#1 (2) {
  ["id"]=>
  string(1) "1"
  ["content"]=>
  string(5) "asdf1"
}
object(tbl_content)#2 (2) {
  ["id"]=>
  string(1) "2"
  ["content"]=>
  string(5) "asdf2"
}
object(tbl_content)#1 (2) {
  ["id"]=>
  string(1) "3"
  ["content"]=>
  string(5) "asdf3"
}


Actual result:
--------------
object(tbl_content)#1 (2) {
  ["id"]=>
  NULL
  ["content"]=>
  string(5) "asdf1"
}
object(tbl_content)#2 (2) {
  ["id"]=>
  NULL
  ["content"]=>
  string(5) "asdf2"
}
object(tbl_content)#1 (2) {
  ["id"]=>
  NULL
  ["content"]=>
  string(5) "asdf3"
}


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-03-25 13:23 UTC] jaap dot taal at gmail dot com
The constructor of the object initializes the id variable to be null (which is needed in other cases).
 [2008-03-25 13:30 UTC] jaap dot taal at gmail dot com
Note that moving the initialization of the id field from the constructor to the declaration fixes this problem, i.e.:

class tbl_content {
  var $id = null;
  var $content;
  function tbl_content() {
//    $this->id = null;
  }
}

However I still think that, from an object oriented perspective, the constructor should be called first thing after creating an object. The implementation of the mysql_fetch_object is wrong.
 [2008-11-02 13:35 UTC] jani@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/


 [2008-11-10 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2010-08-18 12:40 UTC] andrey@php.net
-Assigned To: andrey +Assigned To: mysql
 [2010-11-02 17:32 UTC] felipe@php.net
-Status: No Feedback +Status: Feedback
 [2010-11-02 17:32 UTC] felipe@php.net
Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/


 [2011-01-05 17:28 UTC] uw@php.net
-Status: Feedback +Status: Open -PHP Version: 5.2.5 +PHP Version: Any
 [2011-01-05 17:28 UTC] uw@php.net
Any version affected. Its questionable if we should change this and break BC.
 [2011-01-16 01:10 UTC] kalle@php.net
I think we should fix this behaviour in trunk and make a note about the change in the upgrading files so its highlighted in the manual once released.
 [2011-01-31 12:46 UTC] johannes@php.net
-Status: Assigned +Status: Wont fix
 [2011-01-31 12:46 UTC] johannes@php.net
The mysql extension isn't extended we certainly shouldn't break the compatibility in this extension in any way. New applications should use mysqli or PDO_mysql ...
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Wed Oct 20 23:03:35 2021 UTC