Re-Add PDO::FETCH_PROPS_LATE to PDO::FETCH_CLASS

Info from reyero on IRC:

if you look at the fetchObject() method, if there's $class_name, then it is not stored anywhere
while PDO:FETCH_CLASS is set
so it will break when you actually fetch the object with ->next()
the underlying issue is StatementInterface missing the fetchObject method + StatementPrefetch::fetchObject() being broken
so for our standards, if the method is not in the interface, I think every other code using fetchObject() is a bug

Not being able to enable a core module (locale) on a core supported db-backend (sqlite) sounds like a critical, no?

Why are we using PDO::FETCH_CLASS in the first place? This is a *very* broken feature of PDO that we should stay as far from it as we can.

Some examples of why it is broken: (1) PDO::FETCH_CLASS builds the object *without calling the constructor*, and (2) PDO::FETCH_CLASS builds the object without respecting the visibility modifiers of either the constructor or the properties that are set.

Being implemented in pure PHP, StatementPrefetch cannot reproduce the brokeness of PDO::FETCH_CLASS in all its glory. In particular, we cannot instantiate an object without calling its constructor before PHP 5.4.

I suggest refactoring the calling code from:

    $string = $this->dbStringSelect($conditions)
      ->execute()
      ->fetchObject('Drupal\locale\SourceString');

to something like:

    $values = $this->dbStringSelect($conditions)
      ->execute()
      ->fetchAssoc();

    $string = new SourceString($values);

I agree.

Agree with all of the above and on top of that we should properly document the Query::select() method,
which btw returns StatementInterface|PDOStatement (depending on the driver used)

Fetching into a class is a supported feature. We have unit tests for it:

http://drupalcode.org/project/drupal.git/blob/refs/heads/8.x:/core/modul...

The pre/post constructor problem is also known, and there is handling for that in the code somewhere. (You can toggle it in the driver.)

Since that test is still passing on a regular basis, I'm unclear what the problem is here.

PHP 5.2 supports the PDO::FETCH_PROPS_LATE constant, that runs the constructor before force-feeding the object with the properties from the database. This is not the default behavior, and there is no way for us to emulate the default behavior in plain PHP.

@Gabor: Ah, I see the distinction. Then we need a test for that as well.

@Damien: I don't follow. We're not using the default behavior, are we?

Oh, crap. Looking back over the history, we are:

#298309: DatabaseStatement::execute with PDO::FETCH_CLASS calls __construct() after setting object attributes
#310904: Use early fetch and document why
http://drupal.org/node/315092

Damien: So there's no way to do pre-constructor fetch in a custom statement class? Since we're no longer supporting 5.2 does that give us more options, since there appear to be version-dependency bugs in the previous issues?

I'd hate to drop fetch class entirely...

@Crell, I would support trying to force PDO::FETCH_PROPS_LATE again (in both Statement and StatementPrefetch), as #298309: DatabaseStatement::execute with PDO::FETCH_CLASS calls __construct() after setting object attributes attempted.

Me too. I don't have any bandwidth to work on it, though.

Duplicate of #1567216: DatabaseStatementPrefetch.fetchAll() implementation does not work when $fetch_style parameter is PDO::FETCH_CLASS.

That's not a duplicate, that's just fetchAll, FETCH_CLASS should not be used at all, I think.

Better issue title. For reasons outlined in #6 we should not be supporting this... feature.

Oh and I forgot to tag this.

Hmm I marked the duplicates the wrong way 'round. #1567216: DatabaseStatementPrefetch.fetchAll() implementation does not work when $fetch_style parameter is PDO::FETCH_CLASS this time.

Updated issue summary.

Updated issue summary.

Since this is basically a revert of #310904: Use early fetch and document why, I think it's fair to bring the comment back too. Other than that, RTBC since we now require a PHP version in which that bug is fixed.

Committed to 8.x. Thanks.