all node types are handled here, this should only fail if libxml adds something new, which is highly unlikely. The user would not be able to address this error as its a C programming error not a PHP one, so the message could better be "Unknown node type in libxml datastructure that DOM extension cannot handle." - I don't expect it to be ever seen by anyone

https://www.php.net/manual/en/function.fsockopen.php defines timeout as a float, however Pheanstalk defines it as an integer. That prevents setting it to values such as 0.1 or 0.2 to get sub-second connection timeouts on infrastructures where Beanstlak server is close to the application server.

Feature Request

Summary

I am wondering if there is / will be an effort to support the rest of the CockroachDB internals with Doctrine? The wire protocol for Cockroach is supported by pdo_pgsql however many of the internals of the driver are broken, including

• differently named functions for generating uuid s
• internal schema differences in things like the sequences:

In AbstractPostgreSQLDriver.php line 60:

  An exception occurred while executing 'SELECT min_value, increment_by FROM "ledger_entries_id_seq"':

  SQLSTATE[42703]: Undefined column: 7 ERROR:  column "min_value" does not exist

actual structure is similar in Cockroach:

SELECT * FROM "whatever_id_seq";
 last_value | log_cnt | is_called
------------+---------+-----------
          0 |       0 | t
(1 Zeile)

• different internal column types: https://github.com/cockroachdb/cockroach/issues/19337

and probably more.

In my (amateur) estimation this could be covered by adding a logic in a new \Doctrine\DBAL\Driver\PDOPgSql\Connection class which detects the difference between an underlying Cockroach DB and a PostgresSQL db and returns an appropriate platform.

Is anyone aware of any forks or similar attempts to bridge this compatibility gap? I would also be willing to help!

Many thanks in advance!

Tyler

I agree with @morozov here, you can provide a Cockroach DB platform in the factory of DBAL and provide it as a third party package. Doctrine itself is not going to support this in the near or mid-term future.

@morozov The only argument that counts is that its a convention across all Doctrine projects that a base exception exists that has the name of the component. We haven't changed this convention even though the coding standard was defined in defiance of it.

In addition to that argument, the deprecation seems the smallest, but is actually very nasty, because a catch (DBALException $e) does not trigger the autoloader, as such no deprecation can be triggered. only when the excepiton is actually triggered can we do that. Since that means the code is not running in the happy path, its much more likely that you oversee this while migrating from DBAL 2 to 3.

Most of the other deprecations are either in the factory related code, or directly in execution and fetching. Honestly I don't think we should deprecate those either, we could keep them and just not document them, but it will be much more obvious to users to see once we trigger the deprecations.

There is a big fat warning about it in the documentation as the first sentence about explaining SchemaTool: https://www.doctrine-project.org/projects/doctrine-orm/en/2.7/reference/tools.html#database-schema-generation

Dear community,

I just stumbled over this article https://www.2ndquadrant.com/en/blog/on-rocks-and-sand/ where the benefits of an optimized column alignment are discussed.

I never thought about this before "because doctrine does all this for me". But is this true? When creating the sql statements to create the schema, is the column order optimized?

The rule of thumb to take large columns first looks like doctrine could implement this easily...?

@flaushi This is outside of Doctrine's scope. We do not recommend to use the SchemaTool directly on production / deployment anyways, you are free to optimize the generated DDL SQL statements in a way that reduces the required table space by aligning columns better.

My previous PR #4555 introduced a new error notification callback API. After merging #5857 for PHP 8 as well, this PR moves the error notification API into zend_observer.h and zend_observer.c.

This will produce a more consistent naming for future, where we provide a general observer API into different parts of PHP engine.

A soft goal would be that we can replace all parts of Dtrace support that are currently hardcoded into the engine using this general observer API provided by zend_observer.h at some point in the future, so that dtrace can become an extension instead of being coupled into the engine.

/cc @morrisonlevi @SammyK

Merged in https://github.com/php/php-src/commit/1359a52d5bbab26004c6195d9d8b8fbc720fd701

Reverted to using Driver\DriverException including the alisases in DBALException and Exception\DriverException.

My previous PR #4555 introduced a new error notification callback API. After merging #5857 for PHP 8 as well, this PR moves the error notification API into zend_observer.h and zend_observer.c.

This will produce a more consistent naming for future, where we provide a general observer API into different parts of PHP engine.

A soft goal would be that we can replace all parts of Dtrace support that are currently hardcoded into the engine using this general observer API provided by zend_observer.h, so that dtrace can become an extension instead of being coupled into the engine.

/cc @morrisonlevi @SammyK

EventDispatcher::dispatch API changed between Symfony 3 and 4 and should maybe get streamlined with an adapter.

@nikic Yes it should be, zend_error_impl is called regardless of being "in soap" or not for errors/warnings/... when they occur, this happens outside the php_error_cb which can be replaced, its placed near the error notify callback code, which was also built to always trigger.

@dstogov @nikic I think tihs should get in before RC1 on Tuesday, what do you think?

That gives us time to discuss for 8.1 how to do it with attributes, it seems we would benefit from first results from users to see how we can give them more control.

Merged in https://github.com/php/php-src/commit/ff0e39bb4dbe542f8795dfa1fef491cd3d30aae3

I believe this is from the revert commit, I didn't change this myself.

I am not happy with it myself, the existence of DriverException in both Exception and Driver namespaces is a bit confusing, and its annoying that an alias is necessary.

@greg0ire this sounds a lot like that bug we had early in 2.7 cycle, do you remember what it was?

I have just read that a Query throws a NonUniqueResultException if Query::getOneOrNullResult() or Query::getSingleResult() is called and finds more than one matching result.

Do you think it is feasible? And if not, why?

That is the way we want the API to work, multiple results can lead to the risk of the wrong one being picked without developer noticing.

I'm defining

a Cart entity

    <entity name="Model\Cart" table="cart">
        <id name="id" type="uuid" length="36"/>
        <one-to-many field="items" target-entity="Model\CartItem"  mapped-by="cart">
            <cascade>
                <cascade-persist/>
            </cascade>
        </one-to-many>
    </entity>

and CartItem entity

    <entity name="Model\CartItem" table="cart_item">
        <id name="id" type="uuid" length="36"/>
        <many-to-one field="cart" target-entity="Model\Cart" inversed-by="items">
            <join-column name="cart_id" column-definition="" referenced-column-name="id" on-delete="CASCADE"/>
        </many-to-one>
      </entity>

Where uuid id is a Custom Type

This Doctrine translate to (I edited the real entities and sql to minimize the code)

CREATE TABLE cart (
id VARCHAR(36) CHARACTER SET utf8 NOT NULL COLLATE `utf8_unicode_ci`,
 PRIMARY KEY(id))

and

CREATE TABLE cart_item (
id VARCHAR(36) CHARACTER SET utf8 NOT NULL COLLATE `utf8_unicode_ci`,
 cart_id VARCHAR(255) CHARACTER SET utf8 DEFAULT NULL COLLATE `utf8_unicode_ci`,
 INDEX IDX_F0FE25271AD5CDBF (cart_id),
 PRIMARY KEY(id))

I don't know why generates in CartItem: cart_id VARCHAR(255) If in Cart is: id VARCHAR(36)

And what can I add/changein mapping to the set correct length of the cart_id FK column ?

I add the custom type for more details:

<?php

class UuidType extends StringType
{
    private const LENGTH = 36;

    public function convertToPHPValue($value, AbstractPlatform $platform)
    {
        return empty($value) ? $value : new UuidValueObject($value);
    }

    public function convertToDatabaseValue($value, AbstractPlatform $platform)
    {
        return empty($value) ? $value : (string)$value;
    }

    public function requiresSQLCommentHint(AbstractPlatform $platform)
    {
        return true;
    }

    public function getDefaultLength(AbstractPlatform $platform)
    {
        return self::LENGTH;
    }
}

You need to set the column-definition="VARCHAR(36)" in the join-column. This information is not inherited from the primary key.

... That's hard to describe, I'll try nevertheless :-)

Background

• We use Deferred Explicit as change tracking policy; and we have a single entity which is enough to reproduce the issue.
• The entity is persisted in the database already, and we have loaded it as $entity.

How to reproduce

• call $entityManager->remove($entity);
• modify the entity $entity->setFoo('bar');
• call $entityManager->persist($entity);
• call $entityManager->flush();
• EXPECTED: The entity should be updated in the database.
• ACTUAL: the entity is not updated.

Root Cause Analysis:

• call $entityManager->remove($entity);
• modify the entity $entity->setFoo('bar');
• call $entityManager->persist($entity);
• call $entityManager->flush();
• EXPECTED: The entity should be updated in the database.
• ACTUAL: the entity is not updated.

Duplicate of #8231

@skurfuerst Valid report, please make it a pull request against the 2.7 branch.

I created a project, where the entities have annotations from both Doctrine\ORM\Mapping and MyLib\Annotation, like this:

<?php

namespace App\Entity;

use Doctrine\ORM\Mapping as ORM;
use MyLib\Annotation as MA;

/**
 * @ORM\Entity
 * @ORM\Table(name="users")
 */
class User
{

    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue
     * @MA\Example
     */
    public $id;

    /**
     * @ORM\Column(type="string")
     */
    public $name;

}

Unfortunately I get this error, if I try to run orm:schema-tool:update:

In AnnotationException.php line 54:

  [Semantical Error] The annotation "@MyLib\Annotation\Example" in property App\Entity\User::$id does not exist,
   or could not be auto-loaded.

I created a minimal reproducible example project, it can be found here: https://github.com/ad-test/doctrine-annotation-bug

The documentation says that __clone (and __wakeup) are not save to implement without an id check. But the Instantiator has an isSafeToClone method that checks if there is an __clone method implemented. So is it still necessary to wrap the __clone into the id check?

Thanks!

@sirdiego No, its not necessary anymore, that was before ReflectionClass::newInstanceWithoutConstructor was added in PHP 5.4 or 5.5

Step to reproduce:

1. create model like:

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 **/
class Record {
    /**
     * @var int
     * @ORM\Id
     * @ORM\Column(name="id", type="bigint", options={"unsigned"=true})
     **/
    public $id;

    /** @var \DateTime @ORM\Column(type="datetime_immutable") */
    public $createdAt;
}

2. create DB, ie. run

vendor\doctrine\orm\bin\doctrine.php orm:schema-tool:update --dump-sql --complete --force

3. then update the model by appending this right below the ID column:

    /** @var string @ORM\Column(type="string", length=500) */
    public $name;

4. update the DB, ie. run:

vendor\doctrine\orm\bin\doctrine.php orm:schema-tool:update --dump-sql --complete --force

5. notice, that the column was added at the end of the table, instead of using AFTER (see https://dev.mysql.com/doc/refman/5.7/en/alter-table.html#alter-table-redefine-column) in the update command (in step 4)

I belive this needs to be addressed in the Doctrine\DBAL\Schema\Comparator as it is used for diffing the schema in: https://github.com/doctrine/orm/blob/ccae8f717684dcd871b418444d7ca7155c677169/lib/Doctrine/ORM/Tools/SchemaTool.php#L906

This is a cosmetic thing that you can add yourself if you want to, but its not something that we are going to add to Doctrine DBAL Schema support.

Hi,

I'm trying to load ManyToMany associations on child entities using the parent entity. Here is an example to try to make this clearer:

I have a parent abstract Entity. Let's call it Animal. Then I have two entities inheriting Animal called Dog and Cat. Dog has a ManyToMany relation with DogHouse and Cat a ManyToMany relation with LitterBox. The inheritance type is a CTI

Now when I load all the Animal I want to fetch at the same time DogHouse and LitterBox to avoid several queries when accessing those entities

I've tried a bunch of ways and it either throws errors as DogHouse and LitterBox do not have a relation with Animal or the hydration breaks and instead of a collection of Animal entities I end up with a collection of Animal, DogHouse and LitterBox

I've searched for ages on the Web and haven't found my answer, sadly

Here are examples of the requests I tried :

//In a repository
// Doesn't work as animal doesn't have a relation with doghouse
$this->createQueryBuilder("a")
    ->leftJoin("a.doghouses", "dh")
    ->addSelect("dh");


//In a repository
//Returns a collection of Animals and DogHouses instead of just Animals
$this->createQueryBuilder("a")
    ->leftJoin(DogHouse::class, "dh", "WITH", "a MEMBER OF dg.dogs")
    ->addSelect("dh");

//In a repository
//Doesn't work either as you now have duplicates in your collection between Animal and Dog
$this->createQueryBuilder("a")
    ->leftJoin(Dog::class, "d", "WITH", "d.id = a.id")
    ->addSelect('d')
    ->leftJoin("d.doghouses", "dh")
    ->addSelect("dh");

I don't know if this is possible through DQL/QueryBuilder

Thanks in advance for your help

This is not possible, because inheritance rules are enforced in DQL as they would be in PHP. You can convert it to a native SQL query or rethink your use of inheritance, it looks like it might not be a good fit.

@dstogov @nikic I think tihs should get in before RC1 on Tuesday, what do you think?

That gives us time to discuss for 8.1 how to do it with attributes, it seems we would benefit from first results from users to see how we can give them more control.

The other option is to copy the interface here and add a autoload-dev. Since its just a marker interface with no methods, there is no risk of breaking with or without doctrine/common.

Draft for #8265

As you can see in AttributeReader, we cannot use ReflectionAttribute::newInstance because of how Doctrine Annotations implements named parameters at the moment. Two ways forward:

1. Copy all Doctrine\ORM\Mapping annotation classes to a new namespace and make them use constructor property promotion.
2. release a new version of doctrine/annotations so that we align named argument supports with how PHP 8 does it, so that all classes in Doctrine\ORM\Mapping can introduce a constructor for 2.8

A constructor for each Attribute (annotation) class is needed so that IDEs can typehint them and ReflectionAttribute::newInstance can be used instead of a custom factory approach.

Todos:

• [ ] Actually run this against a php 8 build
• [ ] Adjust tests to make this running

The problem without this change is that we could not use ReflectionAttribute::newInstance then and also would probably confuse IDE autocomplete for attributes as they look for constructor arguments to suggest.

Currently Annotation DocParser does new $annotation($values); if a constructor is detected. This is based on the Annotation base class that existis in the library. We should have another use-case where it checks for constructor but not extending Doctrine\Common\Annotations\Nnnotation and in that case replicate named arguments behavior: @Column(name="foo") maps to a constructor __construct($name).

This is required so we can move all annotation classes to use a constructor in ORM 2.8.

@lcobucci not for a new metadata driver

Problem with this approach is that without a constructor using parameters, IDEs will probably not autocomplete the named properties of attributes. This requires us to duplicate all attribute classes unless we find some clever magic, or adjust the Annotation DocParser case with has_constructor must be changed or broken in some way.

For Doctrine ORM 2.8 we should add a metadata driver using Attributes, based off the AnnotationDriver with some adjustment to account for the missing nested support.

Idea:

• Re-use Doctrine\ORM\Mapping\* annotation classes and add #[Attribute] as needed.
• Flatten @JoinTable by introducing new InverseJoinColumn attribute
• Flatten @Table by allowing Index and UniqueConstraint on the entity/class level.
• Drop support for named queries and named native queries in Attribute based mapping driver due to their nesting complexity.

Having a purely cosmetic thought here, if the naming "toIterable" would be preferrable over "getIterable".

looks like:

$xpath->registerPhpFunctions(['non_existant']);

This pull request adds two new events so that they can be observed from userland. The two new events are

• initializeProxy: called each time a proxy is initialized
• initializePersistentCollection: called each time a persistent collection is initialized.

The use case behind this PR is to provide an hook to be able to detect n+1. See n-plus-one-detector

Thank you for your contribution, but it is unlikely we are going to merge this, especially when the use-case is so narrow.

You can see N+1 queries by using an SQL Logger and inspecting the backtrace already, or by using a Profiler and looking at the execution graphs.

Do you have the stacktrace for the segfault?

@oojacoboo @FabienPapet see my last comment please, it explains what the problem is and it details how this can be fixed. It should be relatively simple if you want to give it a try.

https://bugs.php.net/bug.php?id=80097

Question: Is this the right representation? Also, what about attributes on all reflectors, should we print them as well? so when you echo a ReflectionFunction with an attribute for example.

@guilhermeblanco does this work with goals for Next?

This needs to target 2.8, and the batch size should be globally configurable via Configuration class

Summary

This reverts the rename of DBALException and parts of the DriverException to Exception rename. This is based on discussions in Slack and https://github.com/doctrine/coding-standard/pull/219 that the makes the convention of doctrine prefixing Exceptions to avoid confusion with the global Exception or other namespaces using Exception.

Foremost, the DBALException rename is reverted, because its use is widespread in open source and private projects and Exception renames are an easy source for nasty bugs.

But secondarily the Driver\DriverExeption rename to Driver\Exception is also changed to become Driver\LowLevelDriverException. Keeping the name as Driver\DriverException would have been preferrable, but we already have a Exception\DriverException one hierachy above. This is still a BC break, but people rely very little on Driver\DriverException as is.

You are arguing that its too late to break BC on a coding standard that is 5 years old, with a deterministic 2 lines of XML workaround, and that its better to BC breaks in actual code of Doctrine projects that are 10 years old, with non deterministic code changes?

I fail to see how a coding standard that is unrelated to the primary goal of Doctrine trumps actual code.

@Ocramius Doctrine is in the game of providing a database abstraction and ORM to users, not in quality assurance and static analysis. The documentation even says The Doctrine Coding Standard is a set of rules for PHP_CodeSniffer and applies to all Doctrine projects.

@lcobucci I'd rather have it that the standard grants no room for interpretation, and override rules point at a code smell, instead of the other way around. Ultimtaely the doctrine/coding-standard is for Doctrine projects. So if external users of our standard would need to disable one of our rules and enable one of Slevomat to get to the old behavior, then I am fine with that compared to our projects maintaining large lists of excemptions in their phpcs.xml

@ostrolucky i agree, i was just adding the sniff here so that we have a base to work off, I am considering to see where it should go from there.

@morozov your argument misses point, the DBALException is the base exception of the public API of DBAL. All exceptions extend from it. All these Exception have a name that is not Exception, so they can't be mixed up with the global Exception or any other libraries Exception. It does not make sense to prefix DBALTableNotFoundException, because TableNotFoundException is already unique enough.

It is also not really important that DBALException is named what its named and its being used many times. Maybe some 10 years ago we could have named it DBAL\BaseException, but we didn't.

As for renaming DBALException, take open source code, https://grep.app/search?q=DBALException spread around quite a bit. I checked a few private projects, all of them catch DBALException at some low level points a few times. Its a class that really shouldn't be renamed anymore at this point.

@lcobucci My undrestanding of a coding standard is, that is doesn't affect the outside API a lot. Essentially as a user you wouldn't care about the coding standard and if its changing, because it doesn't change the public API. However this rule changes the convention of the Doctrine project in a way that affects outside users quite massively. As such i would say, we should re-consider having it, and instead enforcing the rule that we already follow implicitly

It has been fully replaced by Github Actions.

Oops :) /cc @kooldev

@morozov are the Postgresql failures unrelated? https://travis-ci.org/github/doctrine/dbal/jobs/725648695 they suddenly started to pop up, 2.10.x last commit is green.

@greg0ire shouldn't the SQL in https://github.com/doctrine/dbal/pull/4256/files#diff-ffff5b2690b3aab7bb35b745b6ca89b9R261 already lead to the DROP INDEX problem as well? wondering how to expand the test to get that failure as well.

@morozov i would rather revert to the old test with the SQL and document it, wouldn't it be better to have a working regression test for this?

The test is only relevant on SQLite in anyways, because the other databases did not have this bug, because they don't have supportsCreateDropForeignKey returning false. So its not problematic that we don't cover the abstraction here, as its more a regression test for Sqlite.

It seems i deprecated the necessary method on Table addUnnamedForeignKeyConstraint, though it wouldn't work anymore anyways at it automatically generates a name now. It would be possible using another deprecated method, but thats also a funky way:

$referencingTable->addNamedForeignKeyConstraint(null, ...);

@morozov it has to be an sqlite specific test, because the schema that breaks it cannot be created with the Schema abstraction, it will always generate a constraint name.

@morozov thats bad, for the compare foreign key that is expected, because I added it as a guard for the new continue 2; statements, but for the functional test that means the meaning was lost while converting it from the specific Sqlite test to the generic test. Will look what happened, but I have an idea.