#46624 [Opn->Bgs]: Fetching results using PDO::FETCH_CLASS set attributes before calling ctor

From: Date: Wed, 19 Nov 2008 23:48:17 +0000
Subject: #46624 [Opn->Bgs]: Fetching results using PDO::FETCH_CLASS set attributes before calling ctor
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-131129@lists.php.net to get a copy of this message
ID: 46624 Updated by: iliaa@php.net Reported By: toby@php.net -Status: Open +Status: Bogus Bug Type: PDO related PHP Version: 5.2.6 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . Previous Comments: ------------------------------------------------------------------------ [2008-11-19 20:14:47] toby@php.net Description: ------------ If you set the PDO fetch mode to PDO::FETCH_CLASS and fetch all results from a result set (aka processed statement), the constructor is called after the properties of the newly created object are set. This is incorrect from the OO point of view, since the ctor may provide sensible default values for properties and prepare the object overall. Therefore property manipulation should happen after the ctor was called. Reproduce code: --------------- $db = $this->getTrackbackDbConection(); $select = $db->query( 'SELECT ... ;' ); $select->setFetchMode( PDO::FETCH_CLASS, 'myCustomClass' ); $result = $select->fetchAll(); class myCustomClass { public $someProperty; public function __construct() { $this->someProperty = 'default' } } Expected result: ---------------- myCustomClass->$someProperty is overwritten by a value from the database. Actual result: -------------- myCustomClass->$someProperty is overwritten by 'default' since __construct() is called after the properties have been set in PDO. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=46624&edit=1

« previous php.bugs (#131129) next »