[DDC-2461] [GH-673] Namespace based command names Created: 17/May/13  Updated: 17/May/13

Status: Reopened
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of hell0w0rd:

Url: https://github.com/doctrine/doctrine2/pull/673

Message:

Symfony console supports auto completion:
``orm:generate:entities`` could called ``o:g:e``



 Comments   
Comment by Doctrine Bot [ 17/May/13 ]

A related Github Pull-Request [GH-673] was closed:
https://github.com/doctrine/doctrine2/pull/673

Comment by Marco Pivetta [ 17/May/13 ]

BC break without advantages

Comment by Doctrine Bot [ 17/May/13 ]

A related Github Pull-Request [GH-673] was reopened:
https://github.com/doctrine/doctrine2/pull/673





[DDC-2460] [GH-672] Simplification example Created: 17/May/13  Updated: 17/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of hell0w0rd:

Url: https://github.com/doctrine/doctrine2/pull/672

Message:

Remove doctrine class loader, one bootstrap file






[DDC-2459] ANSI compliant quote strategy. Created: 17/May/13  Updated: 17/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Minor
Reporter: Fabio B. Silva Assignee: Fabio B. Silva
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In order to simplify and speed up the sql generation
an ANSI quote strategy would be useful.

The implementation would be something like :

<?php
class AnsiQuoteStrategy implements \Doctrine\ORM\Mapping\QuoteStrategy
{
    /**
     * {@inheritdoc}
     */
    public function getColumnName($fieldName, ClassMetadata $class, AbstractPlatform $platform)
    {
        return $class->fieldMappings[$fieldName]['columnName'];
    }

    /**
     * {@inheritdoc}
     */
    public function getTableName(ClassMetadata $class, AbstractPlatform $platform)
    {
        return $class->table['name'];
    }

    /**
     * {@inheritdoc}
     */
    public function getSequenceName(array $definition, ClassMetadata $class, AbstractPlatform $platform)
    {
        return $definition['sequenceName'];
    }

    /**
     * {@inheritdoc}
     */
    public function getJoinColumnName(array $joinColumn, ClassMetadata $class, AbstractPlatform $platform)
    {
        return $joinColumn['name'];
    }

    /**
     * {@inheritdoc}
     */
    public function getReferencedJoinColumnName(array $joinColumn, ClassMetadata $class, AbstractPlatform $platform)
    {
        return $joinColumn['referencedColumnName'];
    }

    /**
     * {@inheritdoc}
     */
    public function getJoinTableName(array $association, ClassMetadata $class, AbstractPlatform $platform)
    {
        return $association['joinTable']['name'];
    }

    /**
     * {@inheritdoc}
     */
    public function getIdentifierColumnNames(ClassMetadata $class, AbstractPlatform $platform)
    {
        return $class->identifier;
    }

    /**
     * {@inheritdoc}
     */
    public function getColumnAlias($columnName, $counter, AbstractPlatform $platform, ClassMetadata $class = null)
    {
        return $platform->getSQLResultCashing($columnName . $counter);
    }
}





[DDC-2458] [GH-671] [DDC-2435] Fix column name with numbers and non alphanumeric characters. Created: 17/May/13  Updated: 17/May/13  Resolved: 17/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of FabioBatSilva:

Url: https://github.com/doctrine/doctrine2/pull/671

Message:

http://www.doctrine-project.org/jira/browse/DDC-2435



 Comments   
Comment by Doctrine Bot [ 17/May/13 ]

A related Github Pull-Request [GH-671] was closed:
https://github.com/doctrine/doctrine2/pull/671

Comment by Fabio B. Silva [ 17/May/13 ]

Merged : https://github.com/doctrine/doctrine2/commit/c9d9b68fa9937218aad05dfca4b3f96b409cfc8e





[DDC-2435] Column name with number and reserved character creates invalid query Created: 08/May/13  Updated: 17/May/13  Resolved: 17/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: 2.3.3
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Dane Lipscombe Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

I have a column name called 1:1 which i map like so
@Column(type="string", name="`1:1`")
Unfortunately, the SQL that get generated does not work in mysql:
SELECT t0.`1:1` AS 112 FROM `table` t0
the problem is with the 'AS 112', if it contained a letter eg. 11a, or was escaped eg. `112` it wound work.



 Comments   
Comment by Fabio B. Silva [ 17/May/13 ]

Fixed : https://github.com/doctrine/doctrine2/commit/c9d9b68fa9937218aad05dfca4b3f96b409cfc8e





[DDC-2457] [GH-670] [DDC-2451] Fix entity listeners serialization Created: 17/May/13  Updated: 17/May/13  Resolved: 17/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of FabioBatSilva:

Url: https://github.com/doctrine/doctrine2/pull/670

Message:

http://www.doctrine-project.org/jira/browse/DDC-2451



 Comments   
Comment by Doctrine Bot [ 17/May/13 ]

A related Github Pull-Request [GH-670] was closed:
https://github.com/doctrine/doctrine2/pull/670

Comment by Fabio B. Silva [ 17/May/13 ]

merged : https://github.com/doctrine/doctrine2/commit/65886fdfeaf38692be5196a59530f56fc3e6ab56





[DDC-2451] Entity listeners class don't work when metadatas are stored in cache Created: 16/May/13  Updated: 17/May/13  Resolved: 17/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, ORM
Affects Version/s: 2.4
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Bruno CHALOPIN Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: event, orm
Environment:

Ubuntu / PHP 5.4.9



 Description   

I'm using entity listeners class to make PostPersist and PostLoad actions per entity and use memcached as the metadata cache. Before the metadatas are in cache, the methods of the entity listeners are properly called but when the metadatas are in cache, they are no longer called. I've also made the test with APC and the result is the same.



 Comments   
Comment by Fabio B. Silva [ 17/May/13 ]

Fixed : https://github.com/doctrine/doctrine2/commit/65886fdfeaf38692be5196a59530f56fc3e6ab56





[DDC-2456] [GH-669] Fixed generating column names for self referencing entity. Created: 17/May/13  Updated: 17/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of hason:

Url: https://github.com/doctrine/doctrine2/pull/669

Message:






[DDC-2454] To-Many OrderBy mechanism should allow many-to-one associations Created: 16/May/13  Updated: 16/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Minor
Reporter: Oleg Namaka Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: association, orderBy


 Description   
class ProductCategory
{
    /**
     * Store
     *
     * @var Store
     *
     * @ORM\ManyToOne(targetEntity="Store")
     * @ORM\JoinColumn(name="store_id", referencedColumnName="store_id")
     */
    private $Store;

    /**
     * storeId (for ordering in Product::ProductCategories only)
     *
     * @var integer
     *
     * @ORM\Column(name="store_id", type="integer")
     */
    private $storeId;
...

class Product
{
    /**
     * Associated categories
     *
     * @var \Doctrine\Common\Collections\Collection
     *
     * @ORM\OneToMany(targetEntity="ProductCategory", mappedBy="Product")
     * @ORM\OrderBy({"storeId"="ASC"})
     */
    private $ProductCategories;
}
}

If it is possible now to sort the ProductCategories collection by the storeId field, it should also be possible to sort them by the Store association. Currently a set of two fields is required: Store as a regular Many-To-One association and if a need arises to be able to use it to sort the One-To-Many collections then storeId needs to be added to the ProductCategory entity. In that case the ProductCategory entity does not pass the schema validation but is perfectly usable.

This should be allowed:

class Product
{
    /**
     * Associated categories
     *
     * @var \Doctrine\Common\Collections\Collection
     *
     * @ORM\OneToMany(targetEntity="ProductCategory", mappedBy="Product")
     * @ORM\OrderBy({"Store"="ASC"})
     */
    private $ProductCategories;
}






[DDC-2455] Setting classes in the entity manager Created: 16/May/13  Updated: 16/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Petter Castro Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: entitymanager


 Description   

I am creating my own bundle in Sf2 which will be used for third libraries, but I need to provide some simple and complex queries from this.
For simple queries i have no problem because I set the repository with the class from the third library.
Something like this:

$this->repository = $this->em->getRepository($className);
$result = $this->repository
->createQueryBuilder("c")
->select('c, d, e')
->join("c.groups", "d")
->join("d.users", "e")
->where("e.id = :userId")
->setParameter("userId", $userId);

return $result->getQuery()->getResult();

But when I need complex queries i have to work with the Entity Manager instead of working with the Repository. So tables are named as MyBundle (Group), but not how the third library named (sf_group). As a consequence the SQL throws an error saying that my table does not exist.
This is how I am trying to retrieve:

$query = $this->em->createQuery("SELECT p FROM Groups p");

I sent the className as the entity to avoid this. Something like:

$query = $this->em->createQuery("SELECT p FROM ".$this->className." p");

However i need a lot of queries with JOINs, so i would have to change every entity name, which is not convenient.

What another way could I implemment this?

Thanks for your help.






[DDC-2452] Additional `WITH` condition in joins between JTI roots cause invalid SQL to be produced Created: 16/May/13  Updated: 16/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: DQL, ORM
Affects Version/s: Git Master
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: dql, sql-walker
Environment:

irrelevant



 Description   

Given a simple Joined Table Inheritance like following:

/**
 * @Entity @Table(name="foo") @InheritanceType("JOINED")
 * @DiscriminatorColumn(name="discr", type="string")
 * @DiscriminatorMap({"foo" = "DDC2452Foo", "bar" = "DDC2452Bar"})
 */
class DDC2452Foo
{
    /** @Id @Column(type="integer") @GeneratedValue */
    public $id;
}

/** @Entity @Table(name="bar") */
class DDC2452Bar extends DDC2452Foo
{
}

Following DQL

SELECT foo1 FROM DDC2452Foo foo1 JOIN DDC2452Foo foo2 WITH 1=1

Will produce broken SQL:

SELECT
    f0_.id AS id0, f0_.discr AS discr1 
FROM 
    foo f0_ 
LEFT JOIN bar b1_ 
    ON f0_.id = b1_.id 
LEFT JOIN foo f2_ 
LEFT JOIN bar b3_ 
    ON f2_.id = b3_.id 
    ON (1 = 1)

(please note the duplicate `ON` in the SQL)

That is caused because of the SQL walker producing the JTI filter with already the `ON` clause in it.

That happens because the JTI join conditions are added in https://github.com/doctrine/doctrine2/blob/2.4.0-BETA2/lib/Doctrine/ORM/Query/SqlWalker.php#L823-L825 (`walkRangeVariableDeclaration`), while the additional defined `WITH` conditions are considered in `walkJoinAssociationDeclaration` later on.

Added a test case and fix at https://github.com/doctrine/doctrine2/pull/668






[DDC-2453] [GH-668] [WIP] Adding failing test for DDC-2452 Created: 16/May/13  Updated: 16/May/13  Resolved: 16/May/13

Status: Closed
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Ocramius:

Url: https://github.com/doctrine/doctrine2/pull/668

Message:

DQL joins between JTI entities produce invalid SQL when additional conditions are inserted via WITH clause

Still working on a fix



 Comments   
Comment by Marco Pivetta [ 16/May/13 ]

Duplicate of DDC-2452





[DDC-2450] Exception throwen when use --dump-sql Created: 16/May/13  Updated: 16/May/13  Resolved: 16/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.3.4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Konstantin Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: None
Environment:

symfony 2.3-dev



 Description   
php app/console doctrine:schema:update --dump-sql > a.sql



  [Doctrine\DBAL\Schema\SchemaException]
  The table with name 'xxx.message76' already exists.



doctrine:schema:update [--complete] [--dump-sql] [--force] [--em[="..."]]


 Comments   
Comment by Marco Pivetta [ 16/May/13 ]

The DBAL can only extract schema definitions from the current DB, so it won't know if there are tables in other databases that are already existing

Comment by Konstantin [ 16/May/13 ]

I haven't this exception week ago. What I'd changed? How can I fix it?

Comment by Marco Pivetta [ 16/May/13 ]

Konstantin what platform are you currently on? Can you provide the mappings to reproduce the problem?





[DDC-2449] Amazon Redshift Support Created: 15/May/13  Updated: 15/May/13

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Major
Reporter: Kirill F Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Amazon Redshift



 Description   

It would be nice to get doctrine compatible with Amazon Redshift. It uses a Postgres connector but there are some differences. I'm currently facing an issue with the primary id, in Redshift the generation of an id is different from Postgres and so I'm getting errors associated with generating an id.

Here are some references that might be useful:
node-orm faced the same issue and seems like they figured it out: https://github.com/dresende/node-orm2/issues/39

Amazon Manual:
http://awsdocs.s3.amazonaws.com/redshift/latest/redshift-dg.pdf






[DDC-2052] Custom tree walkers are not allowed to add new components to the query Created: 02/Oct/12  Updated: 14/May/13

Status: Reopened
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.3
Fix Version/s: 2.4

Type: Improvement Priority: Major
Reporter: Łukasz Cybula Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dql


 Description   

Custom tree walkers have freedom in modifying the AST but when you try to add a new query component (i.e. new join in walkSelectStatement() ) to the AST then the SqlWalker throws an exception because it does not has the new component in its _queryComponents array. I see two possible ways to resolve this:
1. Modify the Parser class in order to allow tree walkers to modify queryComponents and pass changed queryComponents to the SqlWalker
2. Improve SqlWalker so it can extract and prepare needed information about queryComponent based on AST when it does not have them.



 Comments   
Comment by Benjamin Eberlei [ 06/Oct/12 ]

Ok this is much more complicated to allow then i thought. The problem is that the QueryComponents are passed by value, as an array, not by reference. That prevents changing them because this change wouldn't be visible in the output walker.

I can add a method to allow this in the OutputWalker for now, but generally this requires a bigger refactoring on the Query Components.

Comment by Benjamin Eberlei [ 06/Oct/12 ]

Added setQueryComponent() in SQL Walker to allow modification in output walker.

Comment by Łukasz Cybula [ 08/Oct/12 ]

I'm afraid that this doesn't solve the initial problem at all. I'll try to describe it in more details to show what I mean. Suppose we have two doctrine extensions each of which contain its own tree walker. Each of these tree walkers need to modify AST and add new component to it (joined with some component already existing in the query). The first problem is that each tree walker has its own queryComponents array which is not passed between them, although they not necessary need to use queryComponents - they could use only AST. The second, bigger problem is that the Parser class does not know anything about modifications of queryComponents in tree walkers and cannot pass modified version to the OutputWalker. The goal of submitting this issue was to allow adding new components to the query in tree walkers which is not achievable by your fix. I think it may be the first step in the right direction. Maybe TreeWalkerAdapter should have public method getQueryComponents() which would be used by the Parser to pass modified queryComponents between different tree walkers and finally to the OutputWalker ? This would not break backward compatibility and solve this issue. What do you think about it?

Comment by Łukasz Cybula [ 08/Oct/12 ]

I've tried to implement the solution mentioned in previous comment but it's also not so clean and easy as I thought. Each tree walker (including TreeWalkerChain) would have to implement getQueryComponents() and setQueryComponent($alias, array $component) methods. The same with SqlWalker, so the TreeWalker interface should have these methods, which would break BC in some way (walkers that do not inherit from SqlWalker or TreeWalkerAdapter will fail to compile). So maybe my first solution (PR #464) is not so bad for now? In the future queryComponents could be replaced by a special object or could be passed by a reference to allow modifications.

Comment by Benjamin Eberlei [ 09/May/13 ]

Marked as improvement as its not a bug.

A solution might probably implement an object holding all the QueryComponent, implementing ArrayAccess. So that way the state can be shared.

Comment by Marco Pivetta [ 14/May/13 ]

Just hit this while developing an ast walker... Will look into it too since I need it more than soon.

Comment by Marco Pivetta [ 14/May/13 ]

As a VERY UGLY workaround, I used a static variable and a custom sql walker in combination with my AST walker.


namespace Comcom\Versioning\ORM\Query;


use Doctrine\ORM\Query\SqlWalker;

class WorkaroundSqlWalker extends SqlWalker
{
    public function __construct($query, $parserResult, array $queryComponents)
    {
        parent::__construct($query, $parserResult, $queryComponents);

        foreach (VersionWalker::$additionalAliases as $alias => $value) {
            $this->setQueryComponent($alias, $value);
        }
    }
}




[DDC-2448] orm:schema-tool:update reports already updated NUMERIC fields Created: 14/May/13  Updated: 14/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.3.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Francesco Montefoschi Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP 5.3.10-1ubuntu3.6 with Suhosin-Patch (cli) (built: Mar 11 2013 14:31:48)
Mysql version: 5.5.31-0ubuntu0.12.04.1 (Ubuntu)



 Description   

I have a table defined in this way:

CREATE TABLE `my_table` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`subtotal` decimal(10,2) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8;

When I run
php doctrine.php orm:schema-tool:update --dump-sql

I get
ALTER TABLE my_table CHANGE subtotal subtotal NUMERIC(10, 2) DEFAULT NULL;

While of course the field is already updated. The same happens in SQL Server 2008 and Postgres 9.






[DDC-2444] NULL IN CASE WHEN Created: 12/May/13  Updated: 14/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.3.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: vahid sohrabloo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hi
In DQL when i use NULL IN "CASE WHEN" like this
"AVG(CASE WHEN g.speed > 0 THEN g.speed ELSE NULL END)"
Throw this expestion
Unexpected 'NULL'



 Comments   
Comment by Miha Vrhovnik [ 14/May/13 ]

We could say a duplicate of: DDC-2208





[DDC-2447] [GH-667] DQL: Allow parameter name to start with any allowed character Created: 13/May/13  Updated: 13/May/13  Resolved: 13/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of juzna:

Url: https://github.com/doctrine/doctrine2/pull/667

Message:

Especially, do not require it to start with a letter. A *number* is good enough as well. Why is was it not enabled anyway?

It's most useful when parameter names are auto generated, e.g. using sha1 or md5.



 Comments   
Comment by Doctrine Bot [ 13/May/13 ]

A related Github Pull-Request [GH-667] was closed:
https://github.com/doctrine/doctrine2/pull/667





[DDC-2429] Association-Override Problem in XSD Mapping? Created: 05/May/13  Updated: 13/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Fabio B. Silva
Resolution: Unresolved Votes: 0
Labels: None


 Description   

From a mailinglist entry:

I use Doctrine 2.3 in Symfony 2.1.8

I'm using association-overrides in the XML format between several entities. Eclipse shows up several errors.

The first error message is shown in every Doctrine file when I declare the file format as such (for example: https://github.com/thewholelifetolearn/Social-Library/blob/master/src/SocialLibrary/ReadBundle/Resources/config/doctrine/GraphicNovel.orm.xml )

<?xml version="1.0" encoding="UTF-8"?>
<doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xsi:schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping
                  http://doctrine-project.org/schemas/orm/doctrine-mapping.xsd">

Eclipse shows this error :
White spaces are required between publicId and systemId

The error points to the "doctrine-mapping" line

The second error comes up when I change the doctype to (file example: https://gist.github.com/thewholelifetolearn/5462057 ):

<?xml version="1.0" encoding="UTF-8"?>
<doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xsi:schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping
                  https://raw.github.com/doctrine/doctrine2/master/doctrine-mapping.xsd">

But then this error is shown:
cvc-complex-type.2.4.b: The content of element 'association-overrides' is not complete. One of '

{"http://doctrine-project.org/schemas/orm/doctrine-mapping":association-override, WC[##other:"http://doctrine-project.org/schemas/orm/doctrine-mapping"]}

' is expected.

The error points on "<association-overrides>" in Novel.orm.xml (line 8)

Could someone explain me the errors that show up? The first error doesn't seem to disturb Symfony2 but the second messes around the console commands. But it still generates the database.






[DDC-2446] [GH-666] [DDC-2429] Fix xsd definition Created: 13/May/13  Updated: 13/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of FabioBatSilva:

Url: https://github.com/doctrine/doctrine2/pull/666

Message:

http://www.doctrine-project.org/jira/browse/DDC-2429






[DDC-2045] Unit of work use all columns for insert Created: 27/Sep/12  Updated: 13/May/13  Resolved: 23/Jan/13

Status: Closed
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Covie X Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

PHP 5.4.7--pl0-gentoo mysql Ver 14.14 Distrib 5.5.22, for Linux (x86_64)



 Description   

I use MySQL. And I'm OK with default values that will be assigned by DB for columns which values I don't set explicitly. But Doctrine seems to unable to skip some columns when building insert SQL query.

People suggest to use nullable flag to enable desired behaviour. And I don't see how it could help. I checked UnitOfWork.php and BasicEntityPersister.php. There is nothing about nullable.
And doc http://docs.doctrine-project.org/en/latest/reference/limitations-and-known-issues.html says that you cannot use custom persisters so far.

So why not track changes for unsaved entities as well, and don't force applications to generate more traffic with more SQL text and developers to set default values in entity constructors?

I would be glad if I'm mistaken and this feature is already implemented and you describe how to resolve the issue. Thanks



 Comments   
Comment by Marco Pivetta [ 23/Jan/13 ]

Covie X the `nullable` flag is a mapping used in columns. See http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/annotations-reference.html#annref-column

Also, Doctrine does not skip columns since default DB-side values are not supported by the ORM. To have default values, you usually set them in the entity's constructor.

Comment by Covie X [ 13/May/13 ]

Marco, you should be ashamed of the way you treat issues.
RTFM answer when there is real and huge problem, seriously?!





[DDC-2445] [GH-665] oo Add Null in ScalarExpression Created: 12/May/13  Updated: 12/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of vahid-sohrabloo:

Url: https://github.com/doctrine/doctrine2/pull/665

Message:






[DDC-2436] Inheritance on mappedSuperClass Created: 08/May/13  Updated: 10/May/13  Resolved: 10/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Petter Castro Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: mappedsuperclass


 Description   

Sometimes is necessary some associations(many to many) in the mappedSuperClass. This associations should not be lost (inversedBy side and mappedBy ). The only one way to get this, was to implement an abstract class as Single Inheritance Table and then the mappedSuperClass inherit of this. But this is not optimum, because we are losing the OOP, creating classes which should not exist.

I realized of this when i was creating my bundle to be used for some projects, but I needed each project could extends from my class and add some properties or methods according their needs.

This is the link where you can see more details of this:

http://stackoverflow.com/questions/16405556/mapped-super-class-symfony2-2

Thanks for your attention.



 Comments   
Comment by Marco Pivetta [ 10/May/13 ]

Mapped superclasses cannot be referenced as they are only meant to provide some simplification by allowing inherited mappings in child classes.

If you want to enforce some kind of association in third party libraries, you can define interfaces and reference those: then, with a listener (during the onLoadMetadata event), replace the interfaces in mappings with (configured) concrete class names.

Comment by Petter Castro [ 10/May/13 ]

I did it, and everything worked perfectly. However, is there a way to dynamically change the "resolve_target_entities" inside my LoadClassMetadata or inside my php code?.
I would like the user makes this configurations with params from my bundle. In background, my bundle will configure these params for doctrine.
Could i do that?

Thanks again for your attention.

Comment by Petter Castro [ 10/May/13 ]

I was thinking in duplicate some code of yours. Exactly this one:

$def = $container->findDefinition('doctrine.orm.listeners.resolve_target_entity');
foreach ($config['resolve_target_entities'] as $name => $implementation) {
     $def->addMethodCall('addResolveTargetEntity', array(
     $name, $implementation, array()
     ));
}
Comment by Marco Pivetta [ 10/May/13 ]

That's exactly how this has to be done.

Comment by Petter Castro [ 10/May/13 ]

I did but there is a problem.... The service doctrine.orm.listeners.resolve_target_entity is not public. So i can't use it in my bundle. I wouldn't like to duplicate all code from this Service. How could I do?

Comment by Marco Pivetta [ 10/May/13 ]

That's an issue for the DoctrineBundle, not for the ORM.

Comment by Petter Castro [ 10/May/13 ]

Ok thanks a lot for your help. I will redirect my question to them.





[DDC-1970] DiscriminatorMap recursion when using self-reference Created: 06/Aug/12  Updated: 10/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3
Fix Version/s: None
Security Level: All

Type: New Feature Priority: Major
Reporter: Krzysztof Kolasiak Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

I've ran into a problem with self-referencing entity. When fetching an entity, recursion occurs, fetching every related entity defined by ManyToOne relation
(in this example $sponsor), ignoring LAZY or EXTRA_LAZY fetch mode - it executes numerous queries.

/**
 * @ORM\Entity(repositoryClass="Acme\Bundle\UserBundle\Entity\Repository\UserRepository")
 * @ORM\Table(name="f_user")
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="type", type="string")
 * @ORM\DiscriminatorMap({"user_person" = "UserPerson", "user_company" = "UserCompany"})
 */
abstract class UserBase extends FOSUser

/* .... */

    /**
     * @var UserBase
     *
     * @ORM\OneToMany(targetEntity="UserBase", mappedBy="sponsor")
     */
    protected $referrals;

    /**
     * @ORM\ManyToOne(targetEntity="UserBase", inversedBy="referrals")
     * @ORM\JoinColumn(name="sponsor_id", referencedColumnName="id")
     */
    protected $sponsor;



 Comments   
Comment by Alexander [ 14/Aug/12 ]

I have changed this into a feature request because you have hit the limitations of using inheritance and self referencing entities.

Doctrine2 cannot currently lazy load UserBase#$sponsor because we don't know which proxy we have to insert. It can either be UserPerson or UserCompany. In order to know this Doctrine2 has to query the actual object to determine its type. The current strategy is then to load the actual entity because we have all data anyway.

In order to implement this feature we need to insert a proxy instead of the actual entity. If we do that there should be no recursion happening.

Comment by Marco Pivetta [ 21/Feb/13 ]

Reduced priority

Comment by Prathap [ 10/May/13 ]

It'd be great if this is a configurable option.





[DDC-2442] [GH-663] Adding failing test to demonstrate DDC-2432 Created: 09/May/13  Updated: 10/May/13  Resolved: 10/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Ocramius:

Url: https://github.com/doctrine/doctrine2/pull/663

Message:

Attempt to fix DDC-2432 ( http://www.doctrine-project.org/jira/browse/DDC-2432 )

Loading proxies with invalid identifiers will currently mark them as initialized regardless of the failure



 Comments   
Comment by Doctrine Bot [ 09/May/13 ]

A related Github Pull-Request [GH-663] was closed:
https://github.com/doctrine/doctrine2/pull/663





[DDC-2384] [GH-639] Added abillity to use metacolumn as indexBy Created: 02/Apr/13  Updated: 10/May/13  Resolved: 10/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of goetas:

Url: https://github.com/doctrine/doctrine2/pull/639

Message:

Added ability to use meta column as indexBy. Useful if association entities is widely used.
Replace #204 PR



 Comments   
Comment by Doctrine Bot [ 10/May/13 ]

A related Github Pull-Request [GH-639] was closed:
https://github.com/doctrine/doctrine2/pull/639





[DDC-2443] [GH-664] ClassMetadaInfo rename setIdentifierValues() to assignIdentifier() Created: 10/May/13  Updated: 10/May/13  Resolved: 10/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of entering:

Url: https://github.com/doctrine/doctrine2/pull/664

Message:

I saw this @todo so i changed name of method and occurrences on code and documentation.



 Comments   
Comment by Doctrine Bot [ 10/May/13 ]

A related Github Pull-Request [GH-664] was closed:
https://github.com/doctrine/doctrine2/pull/664

Comment by Marco Pivetta [ 10/May/13 ]

Cannot fix in 2.x





[DDC-1884] leftJoin via composite key part not hydrated if joining table solely consists of identifiers Created: 20/Jun/12  Updated: 09/May/13

Status: In Progress
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2.0-RC1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Sander Coolen Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MAMP



 Description   

Suppose I have the following entities:

/**
 * @ORM\Entity
 * @ORM\Table(name="driver")
 */
class Driver
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    private $id;
    
    /**
     * @ORM\Column(type="string", length=255);
     */
    private $name;
    
    /**
     * @ORM\OneToMany(targetEntity="DriverRide", mappedBy="driver")
     */
    private $driverRides;
}
/**
 * @ORM\Entity
 * @ORM\Table(name="driver_ride")
 */
class DriverRide
{
    /**
     * @ORM\Id
     * @ORM\ManyToOne(targetEntity="Driver", inversedBy="driverRides")
     * @ORM\JoinColumn(name="driver_id", referencedColumnName="id")
     */
    private $driver;
    
    /**
     * @ORM\Id
     * @ORM\ManyToOne(targetEntity="Car", inversedBy="carRides")
     * @ORM\JoinColumn(name="car", referencedColumnName="brand")
     */
    private $car;
}
/**
 * @ORM\Entity
 * @ORM\Table(name="car")
 */
class Car
{
    /**
     * @ORM\Id
     * @ORM\Column(type="string", length=25)
     * @ORM\GeneratedValue(strategy="NONE")
     */
    private $brand;
    
    /**
     * @ORM\Column(type="string", length=255);
     */
    private $model;
    
    /**
     * @ORM\OneToMany(targetEntity="DriverRide", mappedBy="car")
     */
    private $carRides;
}

And want to query for Cars that a Driver drove in:

$qb = $em->createQueryBuilder();

$qb->select('d, dr, c')
   ->from('Driver', 'd')
   ->leftJoin('d.driverRides', 'dr')
   ->leftJoin('dr.car', 'c')
   ->where('d.id = ?1') /* some Driver id */
   ->getQuery()->getArrayResult();

Expected results:
I expect to get an array with an index 'driverRides' with an array of Cars (depending on the data of course).

Actual result:
Just an array with Driver data.

When I started doing some testing I found out I get a different result when I add a third column to the DriverRide table that isn't part of the composite primary key.
Now I did get a 'driverRides' array, but with just a single row and not three as I expected to get in my case.

When I removed the composite key and used an auto-generated id-column, everything worked as expected.

Some test data you might want to use:

INSERT INTO `car` (`brand`, `model`) VALUES
('BMW', '7 Series'),
('Crysler', '300'),
('Mercedes', 'C-Class'),
('Volvo', 'XC90');

INSERT INTO `driver` (`id`, `name`) VALUES
(1, 'John Doe'),
(2, 'Foo Bar');

INSERT INTO `driver_ride` (`driver_id`, `car`) VALUES
(1, 'Crysler'),
(1, 'Mercedes'),
(1, 'Volvo'),
(2, 'BMW');


 Comments   
Comment by Benjamin Eberlei [ 05/Jul/12 ]

Can you update to at least 2.2.1 and try again, because this fix here http://www.doctrine-project.org/jira/browse/DDC-1652 look like it could be related to your problem.

Comment by Sander Coolen [ 07/Jul/12 ]

We're already using the 2.2.x-dev package. It does look similar to DDC-1652

Comment by Sander Coolen [ 08/Jul/12 ]

Added testcase on 2.1.x (not the right one unfortunately) branch: https://github.com/doctrine/doctrine2/pull/395

BTW I was adding said testcase on master and got an error similar to DDC-979

Comment by Benjamin Eberlei [ 09/May/13 ]

I upgraded the testcase to master locally, and it seems to fail on Array hydration only now, with a notice:

Exception: [PHPUnit_Framework_Error] Argument 1 passed to Doctrine\ORM\Internal\Hydration\ArrayHydrator::updateResultPointer() must be of the type array, string given, called in /home/benny/code/php/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/ArrayHydrator.php on line 196 and defined

I remember fixing something similar for ObjectHydration (which works for your testcases). Will investigate more when I have time.





[DDC-2440] composer.json is wrong Created: 09/May/13  Updated: 09/May/13  Resolved: 09/May/13

Status: Closed
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Blocker
Reporter: Richard Nicol Assignee: Marco Pivetta
Resolution: Invalid Votes: 1
Labels: None


 Description   

In composer.json for doctrine/doctrine-orm-module there is the following require:
"doctrine/doctrine-module": "0.8.*"

However "0.8.*" does not exist, it should be "0.8.x-dev" or "dev-master". The later would then use the branch alias. Either way this needs changing, because it's stopping the package from being installed or updated.



 Comments   
Comment by Benjamin Eberlei [ 09/May/13 ]

Please open the ticket on the Doctrine ORM Module, this is the ORM bug tracker.

Comment by Richard Nicol [ 09/May/13 ]

Sorry my mistake! I have opened an issue on github here: https://github.com/doctrine/DoctrineORMModule/issues/219 in case anyone ends up here.

Cheers.

Comment by Marco Pivetta [ 09/May/13 ]

DoctrineModule has a 0.8.x branch. Closing





[DDC-2432] Entity can be initialized even if not found Created: 06/May/13  Updated: 09/May/13  Resolved: 09/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.3
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Critical
Reporter: Christoph Roensch Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

I have some data in loose consistency, trying to load a field from a certain entity will yield a EntityNotFoundException. Trying it again, for example if the group is reused in a set that gets iterated, will work but provide an empty/dirty Entity.

try {
  echo $item->getGroup()->getName();
} catch (\Doctrine\ORM\EntityNotFoundException $enfe) {
  // meh
}

Thats probably because the proxies internal methods set _isInitialized_ to true on the first try. Without reverting it in case of the exception...

    public function __load()
    {
        if (!$this->__isInitialized__ && $this->_entityPersister) {
            $this->__isInitialized__ = true;

            if ($this->_entityPersister->load($this->_identifier, $this) === null) {
                throw new \Doctrine\ORM\EntityNotFoundException();
            }
            unset($this->_entityPersister, $this->_identifier);
        }
    }

Is there any reason to do that?



 Comments   
Comment by Marco Pivetta [ 06/May/13 ]

That is specifically there to disallow recursive load operations that may occur - did you already try this with latest master?

Comment by Christoph Roensch [ 07/May/13 ]

I did not exactly use an "Doctrine Proxy". A colleque of me implemented his own proxies, wich instead of loading from an entity manager, load stuff from a webservice. He simply used the template that a normal proxy provided and thats where i found this case, throw exception - return initialized. Wich i found would be valid for real proxies too.

Now i tried to use http://www.doctrine-project.org/blog/doctrine-2-4-beta.html but the composer install just fails because common cant be resolved atm. So i downloaded and compiled all tarballs from github into our project. Now the proxy mechanism seems changed, with an _initializer_ closure instead. Our "Entities" in question won't work with that anymore...

I would have to construct a demo then, implementing real basic proxies with a RDBMS?

Comment by Marco Pivetta [ 07/May/13 ]

Christoph Roensch did you try setting the minimum-stability flag in composer? Give it a try again with 2.4 and ping back - proxies changed a lot since 2.3

Comment by Christoph Roensch [ 08/May/13 ]

I reproduced it with the tutorial application, please have a look at the two commits i made on https://github.com/croensch/doctrine2-orm-tutorial/tree/DDC-2432

Comment by Marco Pivetta [ 09/May/13 ]

Proposed a fix at https://github.com/doctrine/doctrine2/pull/663





[DDC-2441] Incorrect SQL Query being generated Created: 09/May/13  Updated: 09/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Critical
Reporter: Paul Mansell Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Using Doctrine in Symfony 2.2.1 on Windows Platform



 Description   

The following DQL :

SELECT s,ba,c,mno,ss,sws,ccs,cns,cws FROM WLCoreBundle:SIM s INNER JOIN s.billingAccount ba LEFT JOIN s.connection c INNER JOIN s.status ss LEFT JOIN s.workflowStatus sws INNER JOIN c.customerStatus ccs INNER JOIN c.networkStatus cns LEFT JOIN c
.workflowStatus cws INNER JOIN s.mno mno ORDER BY c.msisdn ASC

Produces the following SQL :

SELECT * FROM (SELECT c0_.id AS id0, c0_.iccid AS iccid1, c0_.created AS created2, c0_.updated AS updated3, c0_.spreference AS spreference4, c1_.id ASid5, c1_.account_number AS account_number6, c1_.name AS name7, c1_.address1 AS address18, c1_.address2 AS address29, c1_.address3 AS address310, c1_.address4 AS address411, c1_.address5 AS address512, c1_.address6 AS address613, c1_.email_address AS email_address14, c1_.spreference AS spreference15, c2_.id AS id16, c2_.msisdn AS msisdn17, c2_.local AS local18, c2_.imsi AS imsi19, c2_.data AS data20, c2_.fax AS fax21, c2_.api AS api22, c2_.activation_date AS activation_date23, c2_.contract_end_date AS contract_end_date24, c2_.created AS created25, c2_.updated AS updated26, c2_.spreference AS spreference27, c3_.id AS id28, c3_.ident AS ident29, c3_.label AS label30, c3_.description AS description31, c4_.id AS id32, c4_.ident AS ident33, c4_.label AS label34, c4_.description AS description35, c4_.customer_label AS customer_label36, c4_.customer_description AS customer_description37, c5_.id AS id38, c5_.ident AS ident39, c5_.label AS label40, c5_.description AS description41, c6_.id AS id42, c6_.ident AS ident43, c6_.label AS label44, c6_.description AS description45, c7_.id AS id46, c7_.ident AS ident47, c7_.label AS label48, c7_.description AS description49, c7_.customer_label AS customer_label50, c7_.customer_description AS customer_description51, c8_.id AS id52, c8_.name AS name53, c8_.email_address AS email_address54, c8_.is_active AS is_active55, c8_.spreference AS spreference56, c0_.billing_account AS billing_account57, c0_.customerHierarchy AS customerHierarchy58, c0_.mno AS mno59, c0_.status AS status60, c0_.workflow_status AS workflow_status61, c1_.customer_hierarchy AS customer_hierarchy62, c1_.country AS country63, c1_.tax_rate AS tax_rate64, c1_.currency AS currency65, c1_.status AS status66, c1_.priority AS priority67, c2_.sim AS sim68, c2_.customer_status AS customer_status69, c2_.network_status AS network_status70, c2_.workflow_status AS workflow_status71, ROW_NUMBER() OVER (ORDER BY msisdn17 ASC) AS doctrine_rownum FROM core_sim c0_ WITH (NOLOCK) INNER JOIN core_billing_account c1_ ON c0_.billing_account = c1_.id LEFT JOIN core_connection c2_ ON c0_.id = c2_.sim INNER JOIN core_sim_status c3_ ON c0_.status = c3_.id LEFT JOIN core_sim_workflow_status c4_ ON c0_.workflow_status = c4_.id INNER JOIN core_connection_customer_status c5_ ON c2_.customer_status = c5_.id INNER JOIN core_connection_network_status c6_ ON c2_.network_status = c6_.id LEFT JOIN core_connection_workflow_status c7_ ON c2_.workflow_status = c7_.id INNER JOIN core_mno c8_ ON c0_.mno = c8_.id) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 10

Which returns an error :

SQLSTATE[42S22]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Invalid column name 'msisdn17'.

Same query works fine in Doctrine 2.3






[DDC-2281] Validation against database-first generated xml requires that the column order within a composite primary key match the order the columns are in in mapping xml Created: 06/Feb/13  Updated: 09/May/13

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: 2.3.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Aaron Moore Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In using a database-first approach utilizing orm:convert-mapping to generate xml, the validation and schema-tool reports that my composite primary key (ex. Columns A, C, B) be dropped and added in the order in which the mapping appears in the xml (ex. Columns A, B, C).

These columns are not auto-increment and are simply a mixture of int and varchar.



 Comments   
Comment by Benjamin Eberlei [ 09/May/13 ]

Is the composite key a mix of association and field types?

Comment by Aaron Moore [ 09/May/13 ]

I'm trying to remember the usage as it was a short term project but I believe it is.

For example a user has a userid.

The table in question might have a primary key consisting of the userid and an int representing a year..





[DDC-2280] Database-first convert-mapping to XML fails to add length to varchar primary key in id tag Created: 06/Feb/13  Updated: 09/May/13  Resolved: 09/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: 2.3.2
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Minor
Reporter: Aaron Moore Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

In using orm:convert-mapping xml --from-database the xml that is generated for varchar columns does not receive a length attribute.

Therefore - orm:validate-schema fails and the schema tool reports that the column must change to a varchar(255) when it should be just fine with the varchar that was already there (ex. varchar(10)).

Note: I discovered this on composite keys - unsure whether this is for all or only composite.



 Comments   
Comment by Benjamin Eberlei [ 09/May/13 ]

Fixed





[DDC-2339] [GH-605] DDC-2338 Added failing test for composite foreign key persistance Created: 07/Mar/13  Updated: 09/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of alex88:

Url: https://github.com/doctrine/doctrine2/pull/605

Message:

I've added this test regarding ticket DDC-2338



 Comments   
Comment by Benjamin Eberlei [ 09/May/13 ]

This is documented behavior and would just be an improvement





[DDC-2439] [GH-662] Fixed a code block. Created: 09/May/13  Updated: 09/May/13  Resolved: 09/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of jakzal:

Url: https://github.com/doctrine/doctrine2/pull/662

Message:

Last code block in the [Keeping your Modules independent](http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/cookbook/resolve-target-entity-listener.html) cookbook is broken.

Sphinx does not like the way code was indented. Building the documentation raises the following error:

en/cookbook/resolve-target-entity-listener.rst:121: ERROR: Unexpected indentation.



 Comments   
Comment by Doctrine Bot [ 09/May/13 ]

A related Github Pull-Request [GH-662] was closed:
https://github.com/doctrine/doctrine2/pull/662





[DDC-2335] [GH-603] Add a filter to the import and convert mapping Created: 06/Mar/13  Updated: 09/May/13  Resolved: 09/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of nicolasTheodo:

Url: https://github.com/doctrine/doctrine2/pull/603

Message:

Hi,

I needed to import the mapping of an existing database in order to create doctrine2 entities, but when you run the command, it throw an exception on every table without a primary key.

I tried to use the filter option, but the error still occurs because the exception was throw in the method which get all the metadata informations.

I added a method which get the metadata of some tables according to a filter.

What are your thought bout my issue?



 Comments   
Comment by Doctrine Bot [ 09/May/13 ]

A related Github Pull-Request [GH-603] was closed:
https://github.com/doctrine/doctrine2/pull/603





[DDC-2190] findBy() support finding by a single DateTime but not by multiple DateTime Created: 06/Dec/12  Updated: 09/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File DDC2190Test.php    

 Description   

The following code works:

$repository->findBy(array('date' => new \DateTime()))

but the following code fails as it does not apply the conversion of the date type for each element:

$repository->findBy(array('date' => array(new \DateTime(), new \DateTime('tomorrow')))


 Comments   
Comment by Benjamin Eberlei [ 06/Jan/13 ]

This is actually very hard to implement, the problem is that we only have ARRAY constants for PDO::PARAM_INT and PDO::PARAM_STR - all the other types would require special handling.

Comment by Benjamin Eberlei [ 09/May/13 ]

Attaching failing testcase.

The idea is to have something like "datetime[]" as type and detect this in the SQLParserUtils of DBAL.

Another approach would be to convert the values in the ORM already, before passing to the DBAL.





[DDC-2438] [GH-661] Update annotations-reference.rst Created: 09/May/13  Updated: 09/May/13  Resolved: 09/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of HarmenM:

Url: https://github.com/doctrine/doctrine2/pull/661

Message:

Added missing @JoinColumns in the index



 Comments   
Comment by Doctrine Bot [ 09/May/13 ]

A related Github Pull-Request [GH-661] was closed:
https://github.com/doctrine/doctrine2/pull/661





[DDC-2433] [GH-659] [wip] Pr mapping import Created: 07/May/13  Updated: 09/May/13  Resolved: 09/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of bronze1man:

Url: https://github.com/doctrine/doctrine2/pull/659

Message:

fix 5 bug of command 1.doctrine:mapping:import then 2.doctrine:schema:update

  • column default
  • column unsigned
  • column type char
  • table without auto_increment
  • column comment

wip -> follow rule of contribute to doctrine

  • add patch on master
  • add test


 Comments   
Comment by Benjamin Eberlei [ 09/May/13 ]

Pull Request was deleted.





[DDC-2430] Incorrect results when using ->matching on PersistentCollection Created: 05/May/13  Updated: 09/May/13  Resolved: 09/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Stuart Carnie Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: criteria
Environment:

Ubuntu 12.04 LTS, PHP 5.4.14



 Description   

When using ->matching() on a PersistentCollection that is already loaded, it returns incorrect results when trying to match by id on a relationship.

// NOTE: the user property is a M:1 relationship of $entity
$c = new Criteria(Criteria::expr()->eq('user', $userId));
$res = $entity->getLikes()->matching($c);

// $res is empty, even if $userId exists



 Comments   
Comment by Benjamin Eberlei [ 09/May/13 ]

The problem is that matching a user by just the id doesn't work for in memory here.
You should use Criteria::expr()->eq('user', $user) instead. The ORM shouldnt allow $userId matching, but this is generic functionality we are reusing here, pretty hard to enforce this. I can take a look.

Comment by Benjamin Eberlei [ 09/May/13 ]

Fixed and introduced a BC break for this.

See https://github.com/doctrine/doctrine2/commit/30f90a6f49d46d2f367ac774aa77e0c7ce1a573f#L0R31 for information.





[DDC-2411] Null values get reset when rehydrating an already managed entity Created: 23/Apr/13  Updated: 09/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Simon Garner Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: hydration


 Description   

Scenario:

1) You have an entity with a ManyToOne relation (and probably other kinds too, but this is all I have tested) to another entity which is nullable. For example, let's say you have a Book entity which has an "illustrator" field which refers to a Person entity, representing the person who illustrated the book. If the book is not illustrated then you set the field to null.

2) You fetch a Book (by ID) which has its illustrator set to a particular Person.

3) You set that Book's illustrator to null.

4) Without flushing, you fetch the Book again, using different criteria: for example, by title. Because entities are Identity Mapped, this will run a query but then locate the same instance in memory, and try to hydrate that instance with the old data it just fetched.

5) Any fields on the instance that have modified values retain their new values (for example, if we changed the illustrator to a different Person, this would be retained), BUT any fields on the instance which are null get overwritten with the old data (so if we previously set the illustrator to null, without flushing, it would now be reset to the Person value that it had before).

There seems to be a mistaken assumption here that null values are fields that have not been hydrated, when this is not necessarily the case. Is this the intended behaviour?

The code that causes this behaviour is here: https://github.com/doctrine/doctrine2/blob/e561f47cb2205565eb873f0643637477bfcfc2ff/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php#L471

If you are wondering why anybody would want to fetch the entity again in step 4, my use case for this is the Symfony Validator (but I presume there could be others).

If there are any unique constraints (Symfony ones, not Doctrine ones) on the entity, e.g. if we had a unique constraint on the Book title field, then when validating the Book the Symfony Validator would check if there are already any Book entities with the same title as the Book we're validating. It will find the Book that we are working with, and because entities are identity mapped, it will act upon the same instance, and the situation above occurs.

Code example:

<?php

// Create some entities

$john = new Person();
$john->setName('John Smith');

$jane = new Person();
$jane->setName('Jane Jones');

$joe = new Person();
$joe->setName('Joe Bloggs');

$book = new Book();
$book->setId(123);
$book->setTitle('Book Title');
$book->setIllustrator($john);
$book->setAuthor($jane);

$em->persist($john);
$em->persist($jane);
$em->persist($joe);
$em->persist($book);
$em->flush();

// Now let's try modifying the book

$book = $bookRepository->find(123);
$book->getIllustrator(); // returns Person "John Smith"
$book->getAuthor(); // returns Person "Jane Jones"

// make some changes
$book->setIllustrator(null); // illustrator is now null
$book->setAuthor($joe); // author is now "Joe Bloggs"

// now validate our changes with Symfony Validator
// note: the same effect can also be observed with
// $test = $bookRepository->findBy('title', 'Book Title');
$validator->validate($book);

// what happened to our book??
$book->getIllustrator(); // returns Person "John Smith" <- should be null
$book->getAuthor(); // returns Person "Joe Bloggs" <- correctly retains the new value



 Comments   
Comment by Fabio B. Silva [ 24/Apr/13 ]

Hi Simon,

Could you please try to write a failing test case or paste your entities ?

Cheers

Comment by Benjamin Eberlei [ 09/May/13 ]

Verified by code review that this issue exists, but it will be very tricky to fix, because the null check is there for other reasons as well.





[DDC-2431] XML Not parsed Created: 05/May/13  Updated: 09/May/13  Resolved: 09/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Petter Castro Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: orm, xml
Environment:

Ubuntu 13.04, Symfony2



 Description   

When i try to generate my entities mapping in Symfony2 using XML I always get the same error:

Element '

{http://doctrine-project.org/schemas/orm/doctrine-mapping}

doctrine-mapping': No matching global declaration avail
able for the validation root

I am not adding any column, because first i need to validate the XML which I can't.

<?xml version="1.0" encoding="UTF-8"?>
<orm:doctrine-mapping
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns:orm='http://doctrine-project.org/schemas/orm/doctrine-mapping'
xsi:schemaLocation='http://doctrine-project.org/schemas/orm/doctrine-mapping http://www.doctrine-project.org/schemas/orm/doctrine-mapping.xsd'>

</orm:doctrine-mapping>

As you can figure out, my XML is very simple. I am doing just for the validation testing. After this could be validated, I will map my entities.

Thanks for your help.

Regards,
Peter



 Comments   
Comment by Benjamin Eberlei [ 09/May/13 ]

The Doctrine XSD hooks itself into the global namespace, see http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/xml-mapping.html for usage. It should work when you loose the "xmlns:orm" and define the tags as "<doctrine-mapping>"





[DDC-2387] convert-mapping not working correctly with composite primary keys/foreign keys in 2.4.0-RC1 Created: 03/Apr/13  Updated: 09/May/13  Resolved: 09/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: None
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Major
Reporter: Nicholas Van Dusen Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None
Environment:

Symfony 2.2.0, MySQL 5.1



 Description   

(Apologies if this is somehow a Symfony-specific issue)

I updated my application via Composer yesterday, and received Doctrine 2.4.0-RC1. After this update, generating entities has been problematic under certain circumstances.

Here is an example table in MySQL:

CREATE TABLE `user_email` (
  `user_id` int(10) unsigned NOT NULL COMMENT 'FK to user',
  `email` varchar(254) NOT NULL,
  `email_datasource` smallint(1) unsigned NOT NULL COMMENT 'FK to datasource_code',
  `insert_date` datetime NOT NULL,
  PRIMARY KEY (`user_id`,`email`,`email_datasource`),
  KEY `FK_UserEmail_DataSourceCode` (`email_datasource`),
  CONSTRAINT `FK_UserEmail_User` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

In Doctrine 2.3, the mapping works correctly, and you end up with a 3-part primary key, with a user property mapped to the User entity, and a datasourceCode property mapped to the DatasourceCode entity. All good.

In 2.4, the following error is given: Single id is not allowed on composite primary key in entity UserEmail.

Removing one of the foreign keys in the table (either to User or DatasourceCode) but keeping the primary key set to all 3 columns allows the mapping to work. But, if you then remove one of the columns from the primary key (say, email_datasource) it fails again.



 Comments   
Comment by Benjamin Eberlei [ 04/Apr/13 ]

Can you provide the full stack trace to the exception please?

$e->getTraceAsString();
Comment by Nicholas Van Dusen [ 11/Apr/13 ]

Benjamin, I'm not sure how to get the trace for you, since I'm running from inside the Symfony2 doctrine:mapping:import command line item.

Comment by Christophe Coevoet [ 11/Apr/13 ]

Use the --verbose option when running the command

Comment by Nicholas Van Dusen [ 11/Apr/13 ]

I was able to get a trace for you:

#0 /var/www/html/voxrepublic/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php(1571): Doctrine\ORM\Mapping\MappingException::singleIdNotAllowedOnCompositePrimaryKey('UserEmail')
#1 /var/www/html/voxrepublic/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php(422): Doctrine\ORM\Mapping\ClassMetadataInfo->getSingleIdentifierFieldName()
#2 /var/www/html/voxrepublic/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php(136): Doctrine\ORM\Mapping\ClassMetadataFactory->completeIdGeneratorMapping(Object(Doctrine\ORM\Mapping\ClassMetadata))
#3 /var/www/html/voxrepublic/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php(302): Doctrine\ORM\Mapping\ClassMetadataFactory->doLoadMetadata(Object(Doctrine\ORM\Mapping\ClassMetadata), NULL, false, Array)
#4 /var/www/html/voxrepublic/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php(212): Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata('UserEmail')
#5 /var/www/html/voxrepublic/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php(112): Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor('UserEmail')
#6 /var/www/html/voxrepublic/vendor/doctrine/doctrine-bundle/Doctrine/Bundle/DoctrineBundle/Command/ImportMappingDoctrineCommand.php(108): Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getAllMetadata()
#7 /var/www/html/voxrepublic/vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php(240): Doctrine\Bundle\DoctrineBundle\Command\ImportMappingDoctrineCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#8 /var/www/html/voxrepublic/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php(195): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#9 /var/www/html/voxrepublic/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php(78): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#10 /var/www/html/voxrepublic/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php(106): Symfony\Bundle\FrameworkBundle\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#11 /var/www/html/voxrepublic/app/console(22): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput))
#12 {main}
Comment by Benjamin Eberlei [ 14/Apr/13 ]

The problem is that Doctrine seems to detect that you only have on id field on this entity and then a new function of 2.4 throws this error. I will try to reproduce this with your table. Until then could you show me the var_dump() of the $class variable in Doctrine\ORM\ClassMetadataFactory#completeIdGeneratorMapping()? This would help very much already.

Comment by Maximilian Beck [ 15/Apr/13 ]

I have the same error when using "doctrine:mapping:import"

CREATE  TABLE IF NOT EXISTS `dev_Recipe`.`step` (

  `recipe_id` INT NOT NULL ,

  `step_number` INT NOT NULL ,

  `description` TEXT NULL ,

  `timer` INT NULL ,

  `image` VARCHAR(100) NULL ,

  PRIMARY KEY (`recipe_id`, `step_number`) ,

  INDEX `recipe_id_idx` (`recipe_id` ASC) ,

  INDEX `step_number` (`step_number` ASC) ,

  CONSTRAINT `step_recipe_id`

    FOREIGN KEY (`recipe_id` )

    REFERENCES `dev_Recipe`.`recipe` (`recipe_id` )

    ON DELETE NO ACTION

    ON UPDATE NO ACTION)

ENGINE = InnoDB;
Exception trace:
 () at \htdocs\SF2\vendor\doctrine\orm\lib\Doctrine\ORM\Mapping\MappingException.php:258
 Doctrine\ORM\Mapping\MappingException::singleIdNotAllowedOnCompositePrimaryKey() at \htdocs\SF2\vendor\doctrine\orm\lib\Doctrine\ORM\Mapping\ClassMetadataInfo.php:1571
 Doctrine\ORM\Mapping\ClassMetadataInfo->getSingleIdentifierFieldName() at \htdocs\SF2\vendor\doctrine\orm\lib\Doctrine\ORM\Mapping\ClassMetadataFactory.php:422
 Doctrine\ORM\Mapping\ClassMetadataFactory->completeIdGeneratorMapping() at \htdocs\SF2\vendor\doctrine\orm\lib\Doctrine\ORM\Mapping\ClassMetadataFactory.php:136
 Doctrine\ORM\Mapping\ClassMetadataFactory->doLoadMetadata() at \htdocs\SF2\vendor\doctrine\common\lib\Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory.php:302
 Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata() at \htdocs\SF2\vendor\doctrine\common\lib\Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory.php:212
 Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor() at \htdocs\SF2\vendor\doctrine\common\lib\Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory.php:112
 Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getAllMetadata() at \htdocs\SF2\vendor\doctrine\orm\lib\Doctrine\ORM\Tools\Console\Command\ConvertMappingCommand.php:126
 Doctrine\ORM\Tools\Console\Command\ConvertMappingCommand->execute() at \htdocs\SF2\vendor\doctrine\doctrine-bundle\Doctrine\Bundle\DoctrineBundle\Command\Proxy\ConvertMappingDoctrineCommand.php:59
 Doctrine\Bundle\DoctrineBundle\Command\Proxy\ConvertMappingDoctrineCommand->execute() at \htdocs\SF2\vendor\symfony\symfony\src\Symfony\Component\Console\Command\Command.php:240
 Symfony\Component\Console\Command\Command->run() at \htdocs\SF2\vendor\symfony\symfony\src\Symfony\Component\Console\Application.php:193
 Symfony\Component\Console\Application->doRun() at \htdocs\SF2\vendor\symfony\symfony\src\Symfony\Bundle\FrameworkBundle\Console\Application.php:78
 Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at \htdocs\SF2\vendor\symfony\symfony\src\Symfony\Component\Console\Application.php:106
 Symfony\Component\Console\Application->run() at \htdocs\SF2\app\console:22

"var_dump($class);" returns:

object(Doctrine\ORM\Mapping\ClassMetadata)#470 (36) {
  ["name"]=>
  string(10) "Ingredient"
  ["namespace"]=>
  string(0) ""
  ["rootEntityName"]=>
  string(10) "Ingredient"
  ["customGeneratorDefinition"]=>
  NULL
  ["customRepositoryClassName"]=>
  NULL
  ["isMappedSuperclass"]=>
  bool(false)
  ["parentClasses"]=>
  array(0) {
  }
  ["subClasses"]=>
  array(0) {
  }
  ["namedQueries"]=>
  array(0) {
  }
  ["namedNativeQueries"]=>
  array(0) {
  }
  ["sqlResultSetMappings"]=>
  array(0) {
  }
  ["identifier"]=>
  array(1) {
    [0]=>
    string(12) "ingredientId"
  }
  ["inheritanceType"]=>
  int(1)
  ["generatorType"]=>
  int(1)
  ["fieldMappings"]=>
  array(4) {
    ["ingredientId"]=>
    array(6) {
      ["id"]=>
      bool(true)
      ["fieldName"]=>
      string(12) "ingredientId"
      ["columnName"]=>
      string(13) "ingredient_id"
      ["type"]=>
      string(7) "integer"
      ["unsigned"]=>
      bool(false)
      ["nullable"]=>
      bool(false)
    }
    ["name"]=>
    array(6) {
      ["fieldName"]=>
      string(4) "name"
      ["columnName"]=>
      string(4) "name"
      ["type"]=>
      string(6) "string"
      ["length"]=>
      int(45)
      ["fixed"]=>
      bool(false)
      ["nullable"]=>
      bool(false)
    }
    ["color"]=>
    array(5) {
      ["fieldName"]=>
      string(5) "color"
      ["columnName"]=>
      string(5) "color"
      ["type"]=>
      string(7) "integer"
      ["unsigned"]=>
      bool(false)
      ["nullable"]=>
      bool(false)
    }
    ["img"]=>
    array(6) {
      ["fieldName"]=>
      string(3) "img"
      ["columnName"]=>
      string(3) "img"
      ["type"]=>
      string(6) "string"
      ["length"]=>
      int(45)
      ["fixed"]=>
      bool(false)
      ["nullable"]=>
      bool(true)
    }
  }
  ["fieldNames"]=>
  array(4) {
    ["ingredient_id"]=>
    string(12) "ingredientId"
    ["name"]=>
    string(4) "name"
    ["color"]=>
    string(5) "color"
    ["img"]=>
    string(3) "img"
  }
  ["columnNames"]=>
  array(4) {
    ["ingredientId"]=>
    string(13) "ingredient_id"
    ["name"]=>
    string(4) "name"
    ["color"]=>
    string(5) "color"
    ["img"]=>
    string(3) "img"
  }
  ["discriminatorValue"]=>
  NULL
  ["discriminatorMap"]=>
  array(0) {
  }
  ["discriminatorColumn"]=>
  NULL
  ["table"]=>
  array(1) {
    ["name"]=>
    string(10) "ingredient"
  }
  ["lifecycleCallbacks"]=>
  array(0) {
  }
  ["associationMappings"]=>
  array(1) {
    ["ingredientCategory"]=>
    array(15) {
      ["fieldName"]=>
      string(18) "ingredientCategory"
      ["targetEntity"]=>
      string(18) "IngredientCategory"
      ["mappedBy"]=>
      string(10) "ingredient"
      ["type"]=>
      int(8)
      ["inversedBy"]=>
      NULL
      ["isOwningSide"]=>
      bool(false)
      ["sourceEntity"]=>
      string(10) "Ingredient"
      ["fetch"]=>
      int(2)
      ["cascade"]=>
      array(0) {
      }
      ["isCascadeRemove"]=>
      bool(false)
      ["isCascadePersist"]=>
      bool(false)
      ["isCascadeRefresh"]=>
      bool(false)
      ["isCascadeMerge"]=>
      bool(false)
      ["isCascadeDetach"]=>
      bool(false)
      ["orphanRemoval"]=>
      bool(false)
    }
  }
  ["isIdentifierComposite"]=>
  bool(false)
  ["containsForeignIdentifier"]=>
  bool(false)
  ["idGenerator"]=>
  NULL
  ["sequenceGeneratorDefinition"]=>
  NULL
  ["tableGeneratorDefinition"]=>
  NULL
  ["changeTrackingPolicy"]=>
  int(1)
  ["isVersioned"]=>
  NULL
  ["versionField"]=>
  NULL
  ["reflClass"]=>
  NULL
  ["isReadOnly"]=>
  bool(false)
  ["namingStrategy":protected]=>
  object(Doctrine\ORM\Mapping\DefaultNamingStrategy)#258 (0) {
  }
  ["reflFields"]=>
  array(0) {
  }
  ["_prototype":"Doctrine\ORM\Mapping\ClassMetadataInfo":private]=>
  NULL
}
object(Doctrine\ORM\Mapping\ClassMetadata)#472 (36) {
  ["name"]=>
  string(18) "IngredientCategory"
  ["namespace"]=>
  string(0) ""
  ["rootEntityName"]=>
  string(18) "IngredientCategory"
  ["customGeneratorDefinition"]=>
  NULL
  ["customRepositoryClassName"]=>
  NULL
  ["isMappedSuperclass"]=>
  bool(false)
  ["parentClasses"]=>
  array(0) {
  }
  ["subClasses"]=>
  array(0) {
  }
  ["namedQueries"]=>
  array(0) {
  }
  ["namedNativeQueries"]=>
  array(0) {
  }
  ["sqlResultSetMappings"]=>
  array(0) {
  }
  ["identifier"]=>
  array(1) {
    [0]=>
    string(2) "id"
  }
  ["inheritanceType"]=>
  int(1)
  ["generatorType"]=>
  int(1)
  ["fieldMappings"]=>
  array(3) {
    ["id"]=>
    array(6) {
      ["id"]=>
      bool(true)
      ["fieldName"]=>
      string(2) "id"
      ["columnName"]=>
      string(2) "id"
      ["type"]=>
      string(7) "integer"
      ["unsigned"]=>
      bool(false)
      ["nullable"]=>
      bool(false)
    }
    ["name"]=>
    array(6) {
      ["fieldName"]=>
      string(4) "name"
      ["columnName"]=>
      string(4) "name"
      ["type"]=>
      string(6) "string"
      ["length"]=>
      int(255)
      ["fixed"]=>
      bool(false)
      ["nullable"]=>
      bool(false)
    }
    ["description"]=>
    array(4) {
      ["fieldName"]=>
      string(11) "description"
      ["columnName"]=>
      string(11) "description"
      ["type"]=>
      string(4) "text"
      ["nullable"]=>
      bool(true)
    }
  }
  ["fieldNames"]=>
  array(3) {
    ["id"]=>
    string(2) "id"
    ["name"]=>
    string(4) "name"
    ["description"]=>
    string(11) "description"
  }
  ["columnNames"]=>
  array(3) {
    ["id"]=>
    string(2) "id"
    ["name"]=>
    string(4) "name"
    ["description"]=>
    string(11) "description"
  }
  ["discriminatorValue"]=>
  NULL
  ["discriminatorMap"]=>
  array(0) {
  }
  ["discriminatorColumn"]=>
  NULL
  ["table"]=>
  array(1) {
    ["name"]=>
    string(19) "ingredient_category"
  }
  ["lifecycleCallbacks"]=>
  array(0) {
  }
  ["associationMappings"]=>
  array(2) {
    ["ingredient"]=>
    array(19) {
      ["fieldName"]=>
      string(10) "ingredient"
      ["targetEntity"]=>
      string(10) "Ingredient"
      ["inversedBy"]=>
      string(18) "ingredientCategory"
      ["joinTable"]=>
      array(3) {
        ["name"]=>
        string(30) "ingredient_category_ingredient"
        ["joinColumns"]=>
        array(1) {
          [0]=>
          array(2) {
            ["name"]=>
            string(22) "ingredient_category_id"
            ["referencedColumnName"]=>
            string(2) "id"
          }
        }
        ["inverseJoinColumns"]=>
        array(1) {
          [0]=>
          array(2) {
            ["name"]=>
            string(13) "ingredient_id"
            ["referencedColumnName"]=>
            string(13) "ingredient_id"
          }
        }
      }
      ["type"]=>
      int(8)
      ["mappedBy"]=>
      NULL
      ["isOwningSide"]=>
      bool(true)
      ["sourceEntity"]=>
      string(18) "IngredientCategory"
      ["fetch"]=>
      int(2)
      ["cascade"]=>
      array(0) {
      }
      ["isCascadeRemove"]=>
      bool(false)
      ["isCascadePersist"]=>
      bool(false)
      ["isCascadeRefresh"]=>
      bool(false)
      ["isCascadeMerge"]=>
      bool(false)
      ["isCascadeDetach"]=>
      bool(false)
      ["joinTableColumns"]=>
      array(2) {
        [0]=>
        string(22) "ingredient_category_id"
        [1]=>
        string(13) "ingredient_id"
      }
      ["relationToSourceKeyColumns"]=>
      array(1) {
        ["ingredient_category_id"]=>
        string(2) "id"
      }
      ["relationToTargetKeyColumns"]=>
      array(1) {
        ["ingredient_id"]=>
        string(13) "ingredient_id"
      }
      ["orphanRemoval"]=>
      bool(false)
    }
    ["parent"]=>
    array(19) {
      ["fieldName"]=>
      string(6) "parent"
      ["targetEntity"]=>
      string(18) "IngredientCategory"
      ["joinColumns"]=>
      array(1) {
        [0]=>
        array(2) {
          ["name"]=>
          string(9) "parent_id"
          ["referencedColumnName"]=>
          string(2) "id"
        }
      }
      ["type"]=>
      int(2)
      ["mappedBy"]=>
      NULL
      ["inversedBy"]=>
      NULL
      ["isOwningSide"]=>
      bool(true)
      ["sourceEntity"]=>
      string(18) "IngredientCategory"
      ["fetch"]=>
      int(2)
      ["cascade"]=>
      array(0) {
      }
      ["isCascadeRemove"]=>
      bool(false)
      ["isCascadePersist"]=>
      bool(false)
      ["isCascadeRefresh"]=>
      bool(false)
      ["isCascadeMerge"]=>
      bool(false)
      ["isCascadeDetach"]=>
      bool(false)
      ["sourceToTargetKeyColumns"]=>
      array(1) {
        ["parent_id"]=>
        string(2) "id"
      }
      ["joinColumnFieldNames"]=>
      array(1) {
        ["parent_id"]=>
        string(9) "parent_id"
      }
      ["targetToSourceKeyColumns"]=>
      array(1) {
        ["id"]=>
        string(9) "parent_id"
      }
      ["orphanRemoval"]=>
      bool(false)
    }
  }
  ["isIdentifierComposite"]=>
  bool(false)
  ["containsForeignIdentifier"]=>
  bool(false)
  ["idGenerator"]=>
  NULL
  ["sequenceGeneratorDefinition"]=>
  NULL
  ["tableGeneratorDefinition"]=>
  NULL
  ["changeTrackingPolicy"]=>
  int(1)
  ["isVersioned"]=>
  NULL
  ["versionField"]=>
  NULL
  ["reflClass"]=>
  NULL
  ["isReadOnly"]=>
  bool(false)
  ["namingStrategy":protected]=>
  object(Doctrine\ORM\Mapping\DefaultNamingStrategy)#258 (0) {
  }
  ["reflFields"]=>
  array(0) {
  }
  ["_prototype":"Doctrine\ORM\Mapping\ClassMetadataInfo":private]=>
  NULL
}
object(Doctrine\ORM\Mapping\ClassMetadata)#474 (36) {
  ["name"]=>
  string(6) "Recipe"
  ["namespace"]=>
  string(0) ""
  ["rootEntityName"]=>
  string(6) "Recipe"
  ["customGeneratorDefinition"]=>
  NULL
  ["customRepositoryClassName"]=>
  NULL
  ["isMappedSuperclass"]=>
  bool(false)
  ["parentClasses"]=>
  array(0) {
  }
  ["subClasses"]=>
  array(0) {
  }
  ["namedQueries"]=>
  array(0) {
  }
  ["namedNativeQueries"]=>
  array(0) {
  }
  ["sqlResultSetMappings"]=>
  array(0) {
  }
  ["identifier"]=>
  array(1) {
    [0]=>
    string(8) "recipeId"
  }
  ["inheritanceType"]=>
  int(1)
  ["generatorType"]=>
  int(1)
  ["fieldMappings"]=>
  array(3) {
    ["recipeId"]=>
    array(6) {
      ["id"]=>
      bool(true)
      ["fieldName"]=>
      string(8) "recipeId"
      ["columnName"]=>
      string(9) "recipe_id"
      ["type"]=>
      string(7) "integer"
      ["unsigned"]=>
      bool(false)
      ["nullable"]=>
      bool(false)
    }
    ["name"]=>
    array(6) {
      ["fieldName"]=>
      string(4) "name"
      ["columnName"]=>
      string(4) "name"
      ["type"]=>
      string(6) "string"
      ["length"]=>
      int(255)
      ["fixed"]=>
      bool(false)
      ["nullable"]=>
      bool(false)
    }
    ["description"]=>
    array(4) {
      ["fieldName"]=>
      string(11) "description"
      ["columnName"]=>
      string(11) "description"
      ["type"]=>
      string(4) "text"
      ["nullable"]=>
      bool(true)
    }
  }
  ["fieldNames"]=>
  array(3) {
    ["recipe_id"]=>
    string(8) "recipeId"
    ["name"]=>
    string(4) "name"
    ["description"]=>
    string(11) "description"
  }
  ["columnNames"]=>
  array(3) {
    ["recipeId"]=>
    string(9) "recipe_id"
    ["name"]=>
    string(4) "name"
    ["description"]=>
    string(11) "description"
  }
  ["discriminatorValue"]=>
  NULL
  ["discriminatorMap"]=>
  array(0) {
  }
  ["discriminatorColumn"]=>
  NULL
  ["table"]=>
  array(1) {
    ["name"]=>
    string(6) "recipe"
  }
  ["lifecycleCallbacks"]=>
  array(0) {
  }
  ["associationMappings"]=>
  array(2) {
    ["recipeCategory"]=>
    array(15) {
      ["fieldName"]=>
      string(14) "recipeCategory"
      ["targetEntity"]=>
      string(14) "RecipeCategory"
      ["mappedBy"]=>
      string(6) "recipe"
      ["type"]=>
      int(8)
      ["inversedBy"]=>
      NULL
      ["isOwningSide"]=>
      bool(false)
      ["sourceEntity"]=>
      string(6) "Recipe"
      ["fetch"]=>
      int(2)
      ["cascade"]=>
      array(0) {
      }
      ["isCascadeRemove"]=>
      bool(false)
      ["isCascadePersist"]=>
      bool(false)
      ["isCascadeRefresh"]=>
      bool(false)
      ["isCascadeMerge"]=>
      bool(false)
      ["isCascadeDetach"]=>
      bool(false)
      ["orphanRemoval"]=>
      bool(false)
    }
    ["users"]=>
    array(19) {
      ["fieldName"]=>
      string(5) "users"
      ["targetEntity"]=>
      string(5) "Users"
      ["inversedBy"]=>
      string(12) "recipeRecipe"
      ["joinTable"]=>
      array(3) {
        ["name"]=>
        string(13) "users_recipes"
        ["joinColumns"]=>
        array(1) {
          [0]=>
          array(2) {
            ["name"]=>
            string(16) "recipe_recipe_id"
            ["referencedColumnName"]=>
            string(9) "recipe_id"
          }
        }
        ["inverseJoinColumns"]=>
        array(1) {
          [0]=>
          array(2) {
            ["name"]=>
            string(8) "users_id"
            ["referencedColumnName"]=>
            string(2) "id"
          }
        }
      }
      ["type"]=>
      int(8)
      ["mappedBy"]=>
      NULL
      ["isOwningSide"]=>
      bool(true)
      ["sourceEntity"]=>
      string(6) "Recipe"
      ["fetch"]=>
      int(2)
      ["cascade"]=>
      array(0) {
      }
      ["isCascadeRemove"]=>
      bool(false)
      ["isCascadePersist"]=>
      bool(false)
      ["isCascadeRefresh"]=>
      bool(false)
      ["isCascadeMerge"]=>
      bool(false)
      ["isCascadeDetach"]=>
      bool(false)
      ["joinTableColumns"]=>
      array(2) {
        [0]=>
        string(16) "recipe_recipe_id"
        [1]=>
        string(8) "users_id"
      }
      ["relationToSourceKeyColumns"]=>
      array(1) {
        ["recipe_recipe_id"]=>
        string(9) "recipe_id"
      }
      ["relationToTargetKeyColumns"]=>
      array(1) {
        ["users_id"]=>
        string(2) "id"
      }
      ["orphanRemoval"]=>
      bool(false)
    }
  }
  ["isIdentifierComposite"]=>
  bool(false)
  ["containsForeignIdentifier"]=>
  bool(false)
  ["idGenerator"]=>
  NULL
  ["sequenceGeneratorDefinition"]=>
  NULL
  ["tableGeneratorDefinition"]=>
  NULL
  ["changeTrackingPolicy"]=>
  int(1)
  ["isVersioned"]=>
  NULL
  ["versionField"]=>
  NULL
  ["reflClass"]=>
  NULL
  ["isReadOnly"]=>
  bool(false)
  ["namingStrategy":protected]=>
  object(Doctrine\ORM\Mapping\DefaultNamingStrategy)#258 (0) {
  }
  ["reflFields"]=>
  array(0) {
  }
  ["_prototype":"Doctrine\ORM\Mapping\ClassMetadataInfo":private]=>
  NULL
}
object(Doctrine\ORM\Mapping\ClassMetadata)#476 (36) {
  ["name"]=>
  string(14) "RecipeCategory"
  ["namespace"]=>
  string(0) ""
  ["rootEntityName"]=>
  string(14) "RecipeCategory"
  ["customGeneratorDefinition"]=>
  NULL
  ["customRepositoryClassName"]=>
  NULL
  ["isMappedSuperclass"]=>
  bool(false)
  ["parentClasses"]=>
  array(0) {
  }
  ["subClasses"]=>
  array(0) {
  }
  ["namedQueries"]=>
  array(0) {
  }
  ["namedNativeQueries"]=>
  array(0) {
  }
  ["sqlResultSetMappings"]=>
  array(0) {
  }
  ["identifier"]=>
  array(1) {
    [0]=>
    string(2) "id"
  }
  ["inheritanceType"]=>
  int(1)
  ["generatorType"]=>
  int(1)
  ["fieldMappings"]=>
  array(3) {
    ["id"]=>
    array(6) {
      ["id"]=>
      bool(true)
      ["fieldName"]=>
      string(2) "id"
      ["columnName"]=>
      string(2) "id"
      ["type"]=>
      string(7) "integer"
      ["unsigned"]=>
      bool(false)
      ["nullable"]=>
      bool(false)
    }
    ["name"]=>
    array(6) {
      ["fieldName"]=>
      string(4) "name"
      ["columnName"]=>
      string(4) "name"
      ["type"]=>
      string(6) "string"
      ["length"]=>
      int(45)
      ["fixed"]=>
      bool(false)
      ["nullable"]=>
      bool(false)
    }
    ["description"]=>
    array(6) {
      ["fieldName"]=>
      string(11) "description"
      ["columnName"]=>
      string(11) "description"
      ["type"]=>
      string(6) "string"
      ["length"]=>
      int(45)
      ["fixed"]=>
      bool(false)
      ["nullable"]=>
      bool(true)
    }
  }
  ["fieldNames"]=>
  array(3) {
    ["id"]=>
    string(2) "id"
    ["name"]=>
    string(4) "name"
    ["description"]=>
    string(11) "description"
  }
  ["columnNames"]=>
  array(3) {
    ["id"]=>
    string(2) "id"
    ["name"]=>
    string(4) "name"
    ["description"]=>
    string(11) "description"
  }
  ["discriminatorValue"]=>
  NULL
  ["discriminatorMap"]=>
  array(0) {
  }
  ["discriminatorColumn"]=>
  NULL
  ["table"]=>
  array(1) {
    ["name"]=>
    string(15) "recipe_category"
  }
  ["lifecycleCallbacks"]=>
  array(0) {
  }
  ["associationMappings"]=>
  array(2) {
    ["recipe"]=>
    array(19) {
      ["fieldName"]=>
      string(6) "recipe"
      ["targetEntity"]=>
      string(6) "Recipe"
      ["inversedBy"]=>
      string(14) "recipeCategory"
      ["joinTable"]=>
      array(3) {
        ["name"]=>
        string(22) "recipe_category_recipe"
        ["joinColumns"]=>
        array(1) {
          [0]=>
          array(2) {
            ["name"]=>
            string(18) "recipe_category_id"
            ["referencedColumnName"]=>
            string(2) "id"
          }
        }
        ["inverseJoinColumns"]=>
        array(1) {
          [0]=>
          array(2) {
            ["name"]=>
            string(9) "recipe_id"
            ["referencedColumnName"]=>
            string(9) "recipe_id"
          }
        }
      }
      ["type"]=>
      int(8)
      ["mappedBy"]=>
      NULL
      ["isOwningSide"]=>
      bool(true)
      ["sourceEntity"]=>
      string(14) "RecipeCategory"
      ["fetch"]=>
      int(2)
      ["cascade"]=>
      array(0) {
      }
      ["isCascadeRemove"]=>
      bool(false)
      ["isCascadePersist"]=>
      bool(false)
      ["isCascadeRefresh"]=>
      bool(false)
      ["isCascadeMerge"]=>
      bool(false)
      ["isCascadeDetach"]=>
      bool(false)
      ["joinTableColumns"]=>
      array(2) {
        [0]=>
        string(18) "recipe_category_id"
        [1]=>
        string(9) "recipe_id"
      }
      ["relationToSourceKeyColumns"]=>
      array(1) {
        ["recipe_category_id"]=>
        string(2) "id"
      }
      ["relationToTargetKeyColumns"]=>
      array(1) {
        ["recipe_id"]=>
        string(9) "recipe_id"
      }
      ["orphanRemoval"]=>
      bool(false)
    }
    ["parent"]=>
    array(19) {
      ["fieldName"]=>
      string(6) "parent"
      ["targetEntity"]=>
      string(14) "RecipeCategory"
      ["joinColumns"]=>
      array(1) {
        [0]=>
        array(2) {
          ["name"]=>
          string(9) "parent_id"
          ["referencedColumnName"]=>
          string(2) "id"
        }
      }
      ["type"]=>
      int(2)
      ["mappedBy"]=>
      NULL
      ["inversedBy"]=>
      NULL
      ["isOwningSide"]=>
      bool(true)
      ["sourceEntity"]=>
      string(14) "RecipeCategory"
      ["fetch"]=>
      int(2)
      ["cascade"]=>
      array(0) {
      }
      ["isCascadeRemove"]=>
      bool(false)
      ["isCascadePersist"]=>
      bool(false)
      ["isCascadeRefresh"]=>
      bool(false)
      ["isCascadeMerge"]=>
      bool(false)
      ["isCascadeDetach"]=>
      bool(false)
      ["sourceToTargetKeyColumns"]=>
      array(1) {
        ["parent_id"]=>
        string(2) "id"
      }
      ["joinColumnFieldNames"]=>
      array(1) {
        ["parent_id"]=>
        string(9) "parent_id"
      }
      ["targetToSourceKeyColumns"]=>
      array(1) {
        ["id"]=>
        string(9) "parent_id"
      }
      ["orphanRemoval"]=>
      bool(false)
    }
  }
  ["isIdentifierComposite"]=>
  bool(false)
  ["containsForeignIdentifier"]=>
  bool(false)
  ["idGenerator"]=>
  NULL
  ["sequenceGeneratorDefinition"]=>
  NULL
  ["tableGeneratorDefinition"]=>
  NULL
  ["changeTrackingPolicy"]=>
  int(1)
  ["isVersioned"]=>
  NULL
  ["versionField"]=>
  NULL
  ["reflClass"]=>
  NULL
  ["isReadOnly"]=>
  bool(false)
  ["namingStrategy":protected]=>
  object(Doctrine\ORM\Mapping\DefaultNamingStrategy)#258 (0) {
  }
  ["reflFields"]=>
  array(0) {
  }
  ["_prototype":"Doctrine\ORM\Mapping\ClassMetadataInfo":private]=>
  NULL
}
object(Doctrine\ORM\Mapping\ClassMetadata)#478 (36) {
  ["name"]=>
  string(4) "Step"
  ["namespace"]=>
  string(0) ""
  ["rootEntityName"]=>
  string(4) "Step"
  ["customGeneratorDefinition"]=>
  NULL
  ["customRepositoryClassName"]=>
  NULL
  ["isMappedSuperclass"]=>
  bool(false)
  ["parentClasses"]=>
  array(0) {
  }
  ["subClasses"]=>
  array(0) {
  }
  ["namedQueries"]=>
  array(0) {
  }
  ["namedNativeQueries"]=>
  array(0) {
  }
  ["sqlResultSetMappings"]=>
  array(0) {
  }
  ["identifier"]=>
  array(2) {
    [0]=>
    string(10) "stepNumber"
    [1]=>
    string(6) "recipe"
  }
  ["inheritanceType"]=>
  int(1)
  ["generatorType"]=>
  int(1)
  ["fieldMappings"]=>
  array(4) {
    ["stepNumber"]=>
    array(6) {
      ["id"]=>
      bool(true)
      ["fieldName"]=>
      string(10) "stepNumber"
      ["columnName"]=>
      string(11) "step_number"
      ["type"]=>
      string(7) "integer"
      ["unsigned"]=>
      bool(false)
      ["nullable"]=>
      bool(false)
    }
    ["description"]=>
    array(4) {
      ["fieldName"]=>
      string(11) "description"
      ["columnName"]=>
      string(11) "description"
      ["type"]=>
      string(4) "text"
      ["nullable"]=>
      bool(true)
    }
    ["timer"]=>
    array(5) {
      ["fieldName"]=>
      string(5) "timer"
      ["columnName"]=>
      string(5) "timer"
      ["type"]=>
      string(7) "integer"
      ["unsigned"]=>
      bool(false)
      ["nullable"]=>
      bool(true)
    }
    ["image"]=>
    array(6) {
      ["fieldName"]=>
      string(5) "image"
      ["columnName"]=>
      string(5) "image"
      ["type"]=>
      string(6) "string"
      ["length"]=>
      int(100)
      ["fixed"]=>
      bool(false)
      ["nullable"]=>
      bool(true)
    }
  }
  ["fieldNames"]=>
  array(4) {
    ["step_number"]=>
    string(10) "stepNumber"
    ["description"]=>
    string(11) "description"
    ["timer"]=>
    string(5) "timer"
    ["image"]=>
    string(5) "image"
  }
  ["columnNames"]=>
  array(4) {
    ["stepNumber"]=>
    string(11) "step_number"
    ["description"]=>
    string(11) "description"
    ["timer"]=>
    string(5) "timer"
    ["image"]=>
    string(5) "image"
  }
  ["discriminatorValue"]=>
  NULL
  ["discriminatorMap"]=>
  array(0) {
  }
  ["discriminatorColumn"]=>
  NULL
  ["table"]=>
  array(1) {
    ["name"]=>
    string(4) "step"
  }
  ["lifecycleCallbacks"]=>
  array(0) {
  }
  ["associationMappings"]=>
  array(1) {
    ["recipe"]=>
    array(20) {
      ["fieldName"]=>
      string(6) "recipe"
      ["targetEntity"]=>
      string(6) "Recipe"
      ["id"]=>
      bool(true)
      ["joinColumns"]=>
      array(1) {
        [0]=>
        array(2) {
          ["name"]=>
          string(9) "recipe_id"
          ["referencedColumnName"]=>
          string(9) "recipe_id"
        }
      }
      ["type"]=>
      int(1)
      ["mappedBy"]=>
      NULL
      ["inversedBy"]=>
      NULL
      ["isOwningSide"]=>
      bool(true)
      ["sourceEntity"]=>
      string(4) "Step"
      ["fetch"]=>
      int(2)
      ["cascade"]=>
      array(0) {
      }
      ["isCascadeRemove"]=>
      bool(false)
      ["isCascadePersist"]=>
      bool(false)
      ["isCascadeRefresh"]=>
      bool(false)
      ["isCascadeMerge"]=>
      bool(false)
      ["isCascadeDetach"]=>
      bool(false)
      ["sourceToTargetKeyColumns"]=>
      array(1) {
        ["recipe_id"]=>
        string(9) "recipe_id"
      }
      ["joinColumnFieldNames"]=>
      array(1) {
        ["recipe_id"]=>
        string(9) "recipe_id"
      }
      ["targetToSourceKeyColumns"]=>
      array(1) {
        ["recipe_id"]=>
        string(9) "recipe_id"
      }
      ["orphanRemoval"]=>
      bool(false)
    }
  }
  ["isIdentifierComposite"]=>
  bool(true)
  ["containsForeignIdentifier"]=>
  bool(true)
  ["idGenerator"]=>
  NULL
  ["sequenceGeneratorDefinition"]=>
  NULL
  ["tableGeneratorDefinition"]=>
  NULL
  ["changeTrackingPolicy"]=>
  int(1)
  ["isVersioned"]=>
  NULL
  ["versionField"]=>
  NULL
  ["reflClass"]=>
  NULL
  ["isReadOnly"]=>
  bool(false)
  ["namingStrategy":protected]=>
  object(Doctrine\ORM\Mapping\DefaultNamingStrategy)#258 (0) {
  }
  ["reflFields"]=>
  array(0) {
  }
  ["_prototype":"Doctrine\ORM\Mapping\ClassMetadataInfo":private]=>
  NULL
}
Comment by Benjamin Eberlei [ 09/May/13 ]

Fixed and merged back to 2.3





[DDC-2437] [GH-660] Fixed critical bug with position indexBy in DQL Created: 08/May/13  Updated: 09/May/13  Resolved: 09/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of vlastv:

Url: https://github.com/doctrine/doctrine2/pull/660

Message:



 Comments   
Comment by Doctrine Bot [ 09/May/13 ]

A related Github Pull-Request [GH-660] was closed:
https://github.com/doctrine/doctrine2/pull/660





[DDC-2434] Error generating entities using annotation docblock (in php). Attribute "fetch" is not being generated by Class EntityGenerator Created: 07/May/13  Updated: 09/May/13  Resolved: 09/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.3.3
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Critical
Reporter: André Antônio Lemos de Moraes Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Windows xp, Apache 2.2 and PHP 5.3.15



 Description   

In this part of the code that begins on line 1047 which is generated lines docblock but not being generated attribute fetch.

            $type = null;
            switch ($associationMapping['type']) {
                case ClassMetadataInfo::ONE_TO_ONE:
                    $type = 'OneToOne';
                    break;
                case ClassMetadataInfo::MANY_TO_ONE:
                    $type = 'ManyToOne';
                    break;
                case ClassMetadataInfo::ONE_TO_MANY:
                    $type = 'OneToMany';
                    break;
                case ClassMetadataInfo::MANY_TO_MANY:
                    $type = 'ManyToMany';
                    break;
            }
            $typeOptions = array();

            if (isset($associationMapping['targetEntity'])) {
                $typeOptions[] = 'targetEntity="' . $associationMapping['targetEntity'] . '"';
            }

            if (isset($associationMapping['inversedBy'])) {
                $typeOptions[] = 'inversedBy="' . $associationMapping['inversedBy'] . '"';
            }

            if (isset($associationMapping['mappedBy'])) {
                $typeOptions[] = 'mappedBy="' . $associationMapping['mappedBy'] . '"';
            }

            if ($associationMapping['cascade']) {
                $cascades = array();

                if ($associationMapping['isCascadePersist']) $cascades[] = '"persist"';
                if ($associationMapping['isCascadeRemove']) $cascades[] = '"remove"';
                if ($associationMapping['isCascadeDetach']) $cascades[] = '"detach"';
                if ($associationMapping['isCascadeMerge']) $cascades[] = '"merge"';
                if ($associationMapping['isCascadeRefresh']) $cascades[] = '"refresh"';

                $typeOptions[] = 'cascade={' . implode(',', $cascades) . '}';
            }

            if (isset($associationMapping['orphanRemoval']) && $associationMapping['orphanRemoval']) {
                $typeOptions[] = 'orphanRemoval=' . ($associationMapping['orphanRemoval'] ? 'true' : 'false');
            }

Below is one possible solution.

            $typesFetch = array(
                2 => 'LAZY',
                3 => 'EAGER',
                4 => 'EXTRA_LAZY'
            );

            if(isset($associationMapping['fetch'])) {
                $typeOptions[] = 'fetch="' . $typesFetch[$associationMapping['fetch']] . '"';
            }

Tanks



 Comments   
Comment by Benjamin Eberlei [ 09/May/13 ]

Highlighted code

Comment by Benjamin Eberlei [ 09/May/13 ]

Fixed and will be included in 2.3.4 release





[DDC-2147] Custom annotation in MappedSuperclass Created: 15/Nov/12  Updated: 07/May/13

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, ORM
Affects Version/s: 2.2.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: kluk Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux 3.6.6-1.fc17.x86_64


Attachments: Text File error.log    

 Description   

When you try use custom annotation in mappedsuperclass like here http://pastebin.com/YMxKvcLk and then i try get metadata for class i get this error
Undefined index: fieldName
ClassMetadataInfo.php function addInheritedFieldMapping
Problem is that custom annotation doesnt have fieldName.
Quick fix is add condition to test if fieldName isset.



 Comments   
Comment by kluk [ 15/Nov/12 ]

error log from orm:validate-schema

Comment by Marco Pivetta [ 23/Jan/13 ]

Copying from pastebin:

use \Doctrine\ORM\Mapping as ORM;
use \xxx\Doctrine\Annotation\Entity as re;
use \xxx\Doctrine\Annotation\Forms as rf;
use \Doctrine\Common\Collections;
 
/**
 * @ORM\Entity
 */
class EventPicture extends \Picture
{
 
    /**
     * @ORM\ManyToOne(targetEntity="Event", inversedBy="eventPicture")
     * @ORM\JoinColumn(name="FK_Event", referencedColumnName="id")
     */
    protected $event;
 
}
use \Doctrine\ORM\Mapping as ORM;
use \xxx\Doctrine\Annotation\Entity as re;
use \xxx\Doctrine\Annotation\Forms as rf;
use \Doctrine\Common\Collections;
 
/** @ORM\MappedSuperclass */
class Picture extends \xxx\Doctrine\Entity\BaseEntity
{
 
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="IDENTITY")
     * @var type
     */
    protected $id;
 
    /**
     * @ORM\Column(type="string",unique=true, nullable=false)
     *  @rf\FileUpload(fileSize="php",uploadType="local",fieldName="link",formControl="FileUploadField",image=true)
     *
     */
    protected $link;
 
}

kluk does this happen also with any other simple custom annotation? For example following:

/**
 * @Annotation 
 * @Target({"PROPERTY","ANNOTATION"})
 */
final class Entity implements Annotation
{
    /**
     * @var string
     */
    public $value;
}
Comment by kluk [ 30/Jan/13 ]

the same error when using simple annotation.

 
<?php

use \Doctrine\ORM\Mapping as ORM;
use \xxx\Doctrine\Annotation\Entity as re;
use \xxx\Doctrine\Annotation\Forms as rf;
use \Doctrine\Common\Collections;

/** @ORM\MappedSuperclass */
class Picture extends \xxx\Doctrine\Entity\BaseEntity {

    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="IDENTITY")
     * @var type
     */
    protected $id;

   
    /**
     * @ORM\Column(type="integer")
     * @rf\SetClass({"class","hide"})
     */
    public $value;

    /**
     * @ORM\Column(type="string",unique=true, nullable=true)
     * @rf\FileUpload(fileSize="php",uploadType="local",fieldName="link",formControl="FileUploadField",image=true)
     *
     */
    protected $link;

}

When i remove $value , $picture from class everything goes ok.
Easy fix for me is change ClassMetadataInfo.

    /**
     * INTERNAL:
     * Adds a field mapping without completing/validating it.
     * This is mainly used to add inherited field mappings to derived classes.
     *
     * @param array $fieldMapping
     *
     * @return void
     */
    public function addInheritedFieldMapping(array $fieldMapping)
    {
        if(isset($fieldMapping['fieldName'])){
        $this->fieldMappings[$fieldMapping['fieldName']] = $fieldMapping;
        $this->columnNames[$fieldMapping['fieldName']] = $fieldMapping['columnName'];
        $this->fieldNames[$fieldMapping['columnName']] = $fieldMapping['fieldName'];
        }
    }

But i dont know if this fix can break another part of doctrine.

Comment by Benjamin Eberlei [ 04/May/13 ]

Can you put the code of your annotations online? I can't seem to understand why this happens.

Comment by kluk [ 07/May/13 ]
Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
 
namespace libs\Doctrine\Annotation\Entity;
use Doctrine\Common\Annotations\Annotation;

/** @Annotation */
class CustomMapping extends Annotation
{
    /**
     *
     * @var string
     */
    public $className;
    /**
     * 
     * 
     * @var IQueryable| string
     */
    public $dataSource;
}




[DDC-2424] Removing an inherited entity via a delete cascade constraint does not remove the parent row Created: 02/May/13  Updated: 06/May/13

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.3.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bruno Jacquet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Mysql 5.1.66 / Symfony 2.2.1



 Description   

For a parent class:

/**
 * @ORM\Entity
 * @ORM\Table(name="Base")
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="discr", type="string")
 * @ORM\DiscriminatorMap({"child1" = "Child1", "child2" = "Child2"})
 */

and simple Child1 & Child2 entities.

With another entity (let's call it ExternalEntity) having a bidirectional OneToOne relation owned by Child1:

class Child1 extends Base
{
  /**
   * @ORM\OneToOne(targetEntity="ExternalEntity", inversedBy="xxx")
   * @ORM\JoinColumn(onDelete="CASCADE", nullable=false)
   */
   private theForeignKey;
}

Enough for the context.
The symptoms:

$em->remove(instanceOfExternalEntity);

removes the ExternalEntity row and the Child1 row. But a dangling row in the Base table is still there for the now inexistent Child1 instance.

Though, a manual delete of either the associated Child1 OR Base row and then the ExternalEntity works.

The problem with the cascading deletion of the parent seems to be only present when deleting through a MYSQL cascading delete from another row which has a foreign key on a child. (Not tested with a foreign key on the parent though)



 Comments   
Comment by Benjamin Eberlei [ 04/May/13 ]

Can you show the CREATE TABLE and FOREIGN KEY statements of all the tables involved? It seems the cascade of the foreign keys is not propagated between multiple tables?

Comment by Bruno Jacquet [ 06/May/13 ]

CREATE TABLE Base (id INT AUTO_INCREMENT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;
CREATE TABLE Child1 (id INT NOT NULL, foreignKey INT NOT NULL, UNIQUE INDEX UNIQ_179B6E88E992F5A (foreignKey), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;

ALTER TABLE Child1 ADD CONSTRAINT FK_179B6E88E992F5A FOREIGN KEY (foreignKey) REFERENCES ExternalEntity (id) ON DELETE CASCADE;
ALTER TABLE Child1 ADD CONSTRAINT FK_179B6E8BF396750 FOREIGN KEY (id) REFERENCES Base (id) ON DELETE CASCADE;

Comment by Bruno Jacquet [ 06/May/13 ]

The problem is that, the SQL model never explicitely tells the DB to delete the corresponding Base when Child1 gets removed. It looks like it is handled by the doctrine entity manager layer and not the actual DB engine (Base has no on delete cascade nor foreign key to its children).
So only doctrine can add the logic here because it knows the entity schema. But in this case, when it is deleted from another table, it looks like the special treatment is not triggered.

Comment by Bruno Jacquet [ 06/May/13 ]

Maybe using

cascade={"remove"}

, instead of

onDelete="CASCADE"

to force the cascading process to be handled by doctrine would workaround the bug... But I prefer to have my DB do the logic work as much as possible.





[DDC-2428] [GH-658] UPDATE clause supports ORDER BY and LIMIT Created: 05/May/13  Updated: 05/May/13  Resolved: 05/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of tomglue:

Url: https://github.com/doctrine/doctrine2/pull/658

Message:

Hi there,

I wanted get some feedback on what you thought about supporting ORDER BY and LIMIT for UPDATE statements.

Is there a reason this has not already been implemented?

Thanks



 Comments   
Comment by Doctrine Bot [ 05/May/13 ]

A related Github Pull-Request [GH-658] was closed:
https://github.com/doctrine/doctrine2/pull/658





[DDC-2409] Merge operation tries to add new detached entities to indentity map and load them as proxies Created: 22/Apr/13  Updated: 05/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.1
Fix Version/s: 2.4, 2.3.4
Security Level: All

Type: Bug Priority: Major
Reporter: Oleg Namaka Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None


 Description   
class A
    {
       /**
        *  @ORM\ManyToOne(targetEntity= "B"...
        *  @ORM\JoinColumn(name=" ...
        */
        protected $b;
        
        public function getB()
        {
            return $this->b;
        }
        
        public function setB($b)
        {
            $this->b = $b;
        }
}
    
    class B
	{
       /**
        * As
        *
        * @var \Doctrine\Common\Collections\Collection
        *
        * @ORM\OneToMany(targetEntity="A", mappedBy="B")
        */
		protected $As;
    }
	
	$b = new \B();
	
	$a = $em->find('A', 123);
	
	$a->setB($b);
	
	$em->detach($a);
	
	$em->detach($b);
	
	$b = $em->merge($b); // notice that $b now is merged
	
	$a = $em->merge($a); //  hangs as it creates the proxy for $b and tries to load a though __load even though $b is already managed

Couple of possible issues in the following code from doMerge:

if ($assoc2['type'] & ClassMetadata::TO_ONE) {
                        $other = $prop->getValue($entity);
                        if ($other === null) {
                            $prop->setValue($managedCopy, null);
                        } else if ($other instanceof Proxy && !$other->__isInitialized__) {
                            // do not merge fields marked lazy that have not been fetched.
                            continue;
                        } else if ( ! $assoc2['isCascadeMerge']) {
                            if ($this->getEntityState($other, self::STATE_DETACHED) !== self::STATE_MANAGED) {
                                $targetClass = $this->em->getClassMetadata($assoc2['targetEntity']);
                                $relatedId = $targetClass->getIdentifierValues($other);

                                if ($targetClass->subClasses) {
                                    $other = $this->em->find($targetClass->name, $relatedId);
                                } else {
                                    $other = $this->em->getProxyFactory()->getProxy($assoc2['targetEntity'], $relatedId);
                                    $this->registerManaged($other, $relatedId, array());
                                }
                            }
                            $prop->setValue($managedCopy, $other);
                        }
     $relatedId = $targetClass->getIdentifierValues($other);

$relatedId is emply as the detached $other was never flushed. It should never be used to add this entity to the identityMap ($this->registerManaged($other, $relatedId, array())

$other = $this->em->getProxyFactory()->getProxy($assoc2['targetEntity'], $relatedId);

This should never use the proxy factory for new detached entities as they are already merged back ($b). This method seems to not have any means to find managed $b.

If $b = $em->merge($b); was not called, the method would probably have worked but I think it is not right to rely on that calling or not calling certain methods or their order.



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

Merged Fabios Pull Request

Comment by Oleg Namaka [ 01/May/13 ]

https://github.com/doctrine/doctrine2/pull/655





[DDC-2169] [GH-524] EntityManagerDecorator base class as an extension point for EntityManager Created: 26/Nov/12  Updated: 04/May/13  Resolved: 04/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of lstrojny:

Url: https://github.com/doctrine/doctrine2/pull/524

Message:

As discussed on IRC. Open issues to be discussed:



 Comments   
Comment by Doctrine Bot [ 04/May/13 ]

A related Github Pull-Request [GH-524] was closed:
https://github.com/doctrine/doctrine2/pull/524





[DDC-2201] [GH-537] fixed problems with joined inheritance and composite keys Created: 16/Dec/12  Updated: 04/May/13  Resolved: 04/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Powerhamster:

Url: https://github.com/doctrine/doctrine2/pull/537

Message:

SchemaTool now creates all Id columns not just only the first one.
Insert statement for child entity now contains parameter for additional key columns only once.



 Comments   
Comment by Doctrine Bot [ 04/May/13 ]

A related Github Pull-Request [GH-537] was closed:
https://github.com/doctrine/doctrine2/pull/537





[DDC-2319] [GH-590] DQL Query: process ArrayCollection values to ease development Created: 25/Feb/13  Updated: 04/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of michaelperrin:

Url: https://github.com/doctrine/doctrine2/pull/590

Message:

I added some code to ease "where in" parameter binding.

As you know, when a where condition is added, the object itself can be passed as a parameter and it's id is automatically retrieved:

```php
$queryBuilder = $this
->where('model.category = :category')
->setParameter('category', $category)
;
```
Where `$category` is an object.

But it doesn't work for collections:
```php
$queryBuilder = $this
->where('model.category IN (:categories)')
->setParameter('categories', $categories)
;
```

Where categories is an `ArrayCollection` object (retrieved from a many to one relation for instance).

This doesn't work in the current version of Doctrine, and my PR solved that.

So far, the only solution is to do the following:

```php
$categoryIds = array();

foreach ($categories as $category)

{ $categoryIds[] = $category->getId(); }

$queryBuilder = $this
->where('model.category IN (:category_ids)')
->setParameter('category_ids', $categoryIds)
;
```

And this is pretty borring when you have to do it several times for several entities.

Note that I didn't add any unit test for this feature. Can you explain me where I should add the test?

Thanks!






[DDC-2006] one2many to self inverts table aliasses and creates wrong db query Created: 31/Aug/12  Updated: 04/May/13  Resolved: 04/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Xavier Dekeyster Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

Debian VM, MySQL, Zend-Framework


Attachments: PNG File Screen Shot 2012-08-31 at 14.31.21.png    

 Description   

See attachment for description.



 Comments   
Comment by Fabio B. Silva [ 06/Apr/13 ]

Hi Xavier,

Could you past your entities and mappings please ?

Thanks

Comment by Benjamin Eberlei [ 14/Apr/13 ]

What version of Doctrine are you using? This sounds like a bug that was fixed some time ago

Comment by Benjamin Eberlei [ 04/May/13 ]

The query is correct, "c.parentCategory c2" generates the right query as per your screenshot. Its just not the order of the queries that you want, Native SQL wil help you here.





[DDC-2258] [GH-556] Create queryBuilder from parts. Created: 25/Jan/13  Updated: 04/May/13  Resolved: 04/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of NoUseFreak:

Url: https://github.com/doctrine/doctrine2/pull/556

Message:

Add a feature that can create a queryBuilder from queryBuilder parts.

This can be used when a query is build and needs to be stored somehow and restore it later.



 Comments   
Comment by Doctrine Bot [ 04/May/13 ]

A related Github Pull-Request [GH-556] was closed:
https://github.com/doctrine/doctrine2/pull/556





[DDC-2316] [GH-588] ClassMetadataInfo: use reflection for creating new instance (on PHP >=5.4) Created: 23/Feb/13  Updated: 04/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 3.0
Security Level: All

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Majkl578:

Url: https://github.com/doctrine/doctrine2/pull/588

Message:

On PHP >=5.4, use proper way for instantiating classes without invoking constructor.



 Comments   
Comment by Benjamin Eberlei [ 04/May/13 ]

Scheduling this for 3.0, when we move to php 5.4 or higher requirement





[DDC-2350] [GH-614] ObjectHydrator: fix entity namespaces. Created: 14/Mar/13  Updated: 04/May/13  Resolved: 04/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of jelmersnoeck:

Url: https://github.com/doctrine/doctrine2/pull/614

Message:

  1. Object Hydrator: fix entity namespaces

If you are using Entity Namespace aliases, the ObjectHydrator will throw a notice for an undefined index of your entity namespace.

    1. Problem
      The problem lies in the fact that the prepare() method uses the "className", used in the aliasMap (where you use the namespace alias) to store the local ClassMetadata cache. Though, in a later stage the actual namespace is being used to find this same item.
    1. Fix
      I've changed the way this ClassMetadata cache is built. It now uses the full Entity namespace.


 Comments   
Comment by Doctrine Bot [ 04/May/13 ]

A related Github Pull-Request [GH-614] was closed:
https://github.com/doctrine/doctrine2/pull/614





[DDC-2254] Exporting and restoring a query. Created: 23/Jan/13  Updated: 04/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: Documentation, DQL, ORM
Affects Version/s: Git Master, 2.3.2
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Dries De Peuter Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dql, rebuild, restore, save
Environment:

OSX



 Description   

When you have a queryBuilder and you want to break it down using getDQLParts, You can't restore it by looping over the parts and adding them.

This is what I am doing:

$parts = $qb->getDQLParts();

// save the parts and use them in a different environment.

$newQb = $em->createQueryBuilder();
foreach ($parts as $name => $part) {
  $newQb->add($name, $part);
}


 Comments   
Comment by Dries De Peuter [ 23/Jan/13 ]

I wrote a test showing the issue.

https://github.com/NoUseFreak/doctrine2/commit/8574b79fd3d245532bbe7e310c5cbe083892057a

Comment by Benjamin Eberlei [ 04/May/13 ]

This is not a bug, because restoring queries is not yet a feature of the QueryBuilder. Marking as possible improvement for future.





[DDC-2267] EntityManager throws an exception when trying to flush($entity) on a deleted entity Created: 31/Jan/13  Updated: 04/May/13  Resolved: 04/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.2
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Major
Reporter: Gennady Feldman Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-2309 Invalid behaviour to flush only one e... Resolved

 Description   

$entity = $em->find("Bug", 1);
$em->remove($entity);
$em->flush($entity);

Throws an exception. Works fine with $em->flush() (No $entity provided).

Would be nice to just flush the deleted entity separate from other entities. This technically works for other operations except remove(). The exception claims that the entity is not mapped. It technically can't be mapped since it's set to be deleted.



 Comments   
Comment by Benjamin Eberlei [ 04/May/13 ]

Fixed in 2.3 branch, for 2.3.4





[DDC-2426] XML Mapping XSD: Missing length attribute for complexType id Created: 03/May/13  Updated: 04/May/13  Resolved: 04/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation, Mapping Drivers
Affects Version/s: 2.3.3
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Major
Reporter: Andrew Moore Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

The xsd file for the doctrine XML mapping specification does not allow the complexType id to contain a length property.

This prevents IDEs from giving proper auto-completion for the <id> element.

To fix, simply add the following at line 332 of the xsd:

<xs:attribute name="length" type="xs:NMTOKEN" />





[DDC-2427] Not working orphanRemoval (OneToMany) Created: 03/May/13  Updated: 04/May/13  Resolved: 04/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Dmitry Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: orm

Attachments: File DDC2427Test.php    

 Description   

Not working orphanRemoval (OneToMany). The element from target entity deleted but still available. I Not get any error, just not deleted.

Configuration example:

class SecurityForm implements SecurityEntityInterface
{
...

/**
*

  • @ORM\OneToMany(targetEntity="SecurityFormField", mappedBy="form", cascade= {"persist"}

    , orphanRemoval=true)

  • @ORM\OrderBy( {"order" = "ASC"}

    )
    */
    private $formFields;

....

}



 Comments   
Comment by Benjamin Eberlei [ 04/May/13 ]

Works for me, see code attached

Comment by Benjamin Eberlei [ 04/May/13 ]

Please provide a failing testcase if you wan't to reopen the ticket.





[DDC-2425] Parent entity sometimes fails to load when validating/updating schema. Created: 03/May/13  Updated: 03/May/13  Resolved: 03/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Trivial
Reporter: Scott Gibson Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: Cli, orm, schematool
Environment:

Debian 6.0.6 x64



 Description   

Should not have reported, was a stupid mistake on my part.






[DDC-2167] [GH-522] [DDC-2166] Refactor identity hash generation Created: 25/Nov/12  Updated: 01/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of beberlei:

Url: https://github.com/doctrine/doctrine2/pull/522

Message:

This work prepares for the merge of GH-232, allowing more complex and robust identifier hash generation.






[DDC-2133] Issue with Query::iterate and query mixed results Created: 09/Nov/12  Updated: 01/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2.1
Fix Version/s: 3.0
Security Level: All

Type: Bug Priority: Major
Reporter: Oleg Namaka Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-1314 DQL permits partial select using SQL Resolved

 Description   

Consider this code:

$dql = "
    SELECT Page, Product.name
    FROM Dlayer\\Entity\\Page Page
    INNER JOIN Page.Product Product
    ";
$q = ($em->createQuery($dql));
foreach ($q->iterate() as $entry) {
  $page = $entry[0][0];
  $name = $entry[0]['name'];
}

This results with undefined index: 'name' for the second entry.

First result keys are (notice just one array element with index 0):

0
array(2) {
  [0] =>
  int(0)
  [1] =>
  string(4) "name"
} 

but all others are different (notice two array elements with index 0 and the other one that is incrementing):

the second one:
0
array(1) {
  [0] =>
  int(0)
}
1
array(1) {
  [0] =>
  string(4) "name"
} 
the third one:
0
array(1) {
  [0] =>
  int(0)
}
2
array(1) {
  [0] =>
  string(4) "name"
} 

What's wrong with this approach? Is it a bug or mixed results should not be used with the iterate method?



 Comments   
Comment by Benjamin Eberlei [ 12/Nov/12 ]

This is a known issue that we don't have found a BC fix for and as I understand Guilherme Blanco requires considerable refactoring.





[DDC-1314] DQL permits partial select using SQL Created: 02/Aug/11  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.1
Fix Version/s: 3.0
Security Level: All

Type: Bug Priority: Minor
Reporter: Daniel Beresh Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None
Environment:

Mac OS X 10.6.7, PHP 5.3.5, Doctrine 2.1.0


Attachments: File IteratableHydratorTest.php    
Issue Links:
Duplicate
duplicates DDC-2133 Issue with Query::iterate and query m... Open

 Description   

The following code is not correct DQL and should (I think?) throw an error:

$query = $em->createQuery("SELECT g.id, g.name FROM Entity\Group g ORDER BY g.name ASC");

...to force the user to use SELECT partial g.

{id,name}

...

Instead, it causes very funny behaviour. eg. when iterating, objects are passed to the foreach in the following pattern:

$groups = $query->iterate();
foreach(...) {
1st time: $groups = array( [0] => object )
2nd time: $groups = array( [1] => object )
3rd time: $groups = array( [2] => object )
}



 Comments   
Comment by Benjamin Eberlei [ 06/Aug/11 ]

The incrementation of the return value is a bug, but SELECT g.id, g.name is valid DQL. You hydrate the values as scalars. What is funny is why it even returns an object in this case.

Comment by Guilherme Blanco [ 11/Dec/11 ]

Added failing test case.
Currently it is not easily doable without larger refactoring of Hydrators.
I'll keep this opened, but my 2 attempts failed.

Comment by Guilherme Blanco [ 23/Jun/12 ]

Scheduled for 3.0 since we're going to refactor the hydrators

Comment by Benjamin Eberlei [ 01/May/13 ]

Duplicate of DDC-2133 (better description)





[DDC-1908] Symfony 2 Doctrine join tables error Created: 05/Jul/12  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Alex Koch Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux, Apache, mysql



 Description   

Hello developers of Doctrine. I appreiate your work on a such complicated project. So seems I'found a bug in Doctrine in generating SQL
I had written this issue on Symfony forum but noone is answering, so maybe I've found the bug of Doctrine or FOSUserBundle
I'm using Symfony 2.0.12, so I've installed as git submodules FOSUserBundle, created User Entity with one-to-one relationship with Company Entity, here goes the code:

<?php

namespace AV\TradeBundle\Entity;

use FOS\UserBundle\Entity\User as BaseUser;
use Doctrine\ORM\Mapping as ORM;

/**

    @ORM\Entity

    @ORM\Table(name="fos_user")
    /
    class User extends BaseUser
    {
    /*
        @ORM\Id
        @ORM\Column(type="integer")
        @ORM\GeneratedValue(strategy="AUTO") */ protected $id;

    /**
        @var company *
        @ORM\OneToOne(targetEntity="Companies", mappedBy="user") * */ private $company;

    public function construct()
    {
    parent::construct();
    // your own logic
    }

    public function getCompany() {
    return $this->company;
    }

    public function setCompany($company) {
    $this->company = $company;
    }
    }

and piece of Company Entity:

<?php
/**
* @var user
*
* @ORM\OneToOne(targetEntity="user", inversedBy="company")
* @ORM\JoinColumn(name="user_id", referencedColumnName="id")
*/
private $user;

When creating fixtures I'm using such method (all references are set, and I have checked for foreign keys in DB - everything is fine)
$this->container->get('fos_user.user_manager')->createUser($user);
When I'm trying to login I see such error:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 't46.id' in 'on clause'

The whole SELECT statement that I found in logs sounds like this one:

SELECT t0.username AS username1, t0.username_canonical AS username_canonical2, t0.email AS email3, t0.email_canonical AS email_canonical4, t0.enabled AS enabled5,
 t0.salt AS salt6, t0.password AS password7, t0.last_login AS last_login8, t0.locked AS locked9, t0.expired AS expired10, t0.expires_at AS expires_at11, 
t0.confirmation_token AS confirmation_token12, t0.password_requested_at AS password_requested_at13, t0.roles AS roles14, t0.credentials_expired AS credentials_expired15,
 t0.credentials_expire_at AS credentials_expire_at16, t0.id AS id17, t18.id AS id19, t18.egrpou AS egrpou20, t18.business_form AS business_form21, t18.title AS title22, 
t18.phone_code AS phone_code23, t18.phone_country_code AS phone_country_code24, t18.phone AS phone25, t18.fax_code AS fax_code26, 
t18.fax_country_code AS fax_country_code27, t18.fax AS fax28, t18.website AS website29, t18.fio AS fio30, t18.birthday AS birthday31, t18.firm_created AS firm_created32, 
t18.employees_count AS employees_count33, t18.logo AS logo34, t18.zip AS zip35, t18.street AS street36, t18.position AS position37, t18.thumb_logo AS thumb_logo38, 
t18.description AS description39, t18.created_at AS created_at40, t18.email AS email41, t18.cities_id AS cities_id42, t18.regions_id AS regions_id43, t18.countries_id AS countries_id44,
 t18.user_id AS user_id45 FROM fos_user t0 LEFT JOIN companies t18 ON t18.user_id = t46.id WHERE t0.username_canonical = ? (["cfyzz"]) [] []

Does anyone know why it's not t0 in join condition but t46?
If needed I'll show my deps.lock, maybe such situation was already fixed, but I was googling for answer for several days - and nothing.
Thanks in advance



 Comments   
Comment by Benjamin Eberlei [ 05/Jul/12 ]

Fixed formatting

Comment by Benjamin Eberlei [ 05/Jul/12 ]

What version of Doctrine are you using? you can check in vendor/doctrine-orm/lib/Doctrine/ORM/Version.php

Comment by Alex Koch [ 06/Jul/12 ]

Thanks, Benjamin, for so quick answer.
I've checked the file you mentioned - the version is "2.1.6"

Comment by Benjamin Eberlei [ 01/May/13 ]

This was fixed in later versions.





[DDC-2176] Illegal offset type in isset or empty in UnitOfWork Created: 28/Nov/12  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Yves Berkholz Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: unitofwork


 Description   

Steps to reproduce the problem?

  • A custom DBAL type, that extends a scalar build-in type e.g. DBAL\Types\StringType
  • convertToPHPValue of custom DBAL type returns an instance of a class (implements __toString method)
  • Custom DBAL type is used as primary key in an entity
  • initially persist entity and flush entity manager
  • modify entity (keep same primary key) and persist entity again causes:

    Warning: Illegal offset type in isset or empty in vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php line 2407

I guess the solution in Doctrine\ORM\Internal\Hydration namespace by explicit converting result of convertToPHPValue if result is not a scalar value.



 Comments   
Comment by Marco Pivetta [ 23/Jan/13 ]

This one will introduce way too much overhead. We don't really support identifiers that are custom object types.

What is the exact version of the ORM? I couldn't spot anything at line 2407.

Comment by Yves Berkholz [ 24/Jan/13 ]

I use a dev branch and updated the version since creation of the report, hence the line number changed to 2466.

UnitOfWork.php
} else {
	$entity = $this->newInstance($class);
	$oid    = spl_object_hash($entity);

	$this->entityIdentifiers[$oid]  = $id;
	$this->entityStates[$oid]       = self::STATE_MANAGED;
	$this->originalEntityData[$oid] = $data;

	$this->identityMap[$class->rootEntityName][$idHash] = $entity; // <- 2466

	if ($entity instanceof NotifyPropertyChanged) {
		$entity->addPropertyChangedListener($this);
	}

	$overrideLocalValues = true;
}

Ok, I understand the overhead problem. I only tried to create a custom enum type that is represented by a class.
But i solved this by converting the value within the getter/setter of entity class.
It would have been nice to do this in the DBAL type, but it works that way.
Therefore, you might close the report or move it on a far future version "wishlist".
Anyway, thank for your time.

Nevertheless the information you requested:
Composer: doctrine/orm [2.3.x-dev fdd0af3]
git reference: fdd0af34e6fced967b8751bc3e4792c11ef86d57

Additionally, exception trace might help

 
() at D:/projects/{projectname}/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:2466
 Symfony/Component/HttpKernel/Debug/ErrorHandler->handle() at D:/projects/{projectname}/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:2466
 Doctrine/ORM/UnitOfWork->createEntity() at D:/projects/{projectname}/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/SimpleObjectHydrator.php:135
 Doctrine/ORM/Internal/Hydration/SimpleObjectHydrator->hydrateRowData() at D:/projects/{projectname}/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/SimpleObjectHydrator.php:50
 Doctrine/ORM/Internal/Hydration/SimpleObjectHydrator->hydrateAllData() at D:/projects/{projectname}/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php:111
 Doctrine/ORM/Internal/Hydration/AbstractHydrator->hydrateAll() at D:/projects/{projectname}/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:678
 Doctrine/ORM/Persisters/BasicEntityPersister->load() at D:/projects/{projectname}/vendor/doctrine/orm/lib/Doctrine/ORM/EntityRepository.php:171
 Doctrine/ORM/EntityRepository->findOneBy() at D:/projects/{projectname}/vendor/doctrine/orm/lib/Doctrine/ORM/EntityRepository.php:211
 Doctrine/ORM/EntityRepository->__call() at D:/projects/{projectname}/vendor/{customvendor}/lib-doctrine/src/{VendorNs}/Lib/Doctrine/DataFixtures/AbstractBaseFixture.php:123
 {VendorNs}/Lib/Doctrine/ORM/Repository/BaseLookupRepository->findOneById() at D:/projects/{projectname}/vendor/{customvendor}/lib-doctrine/src/{VendorNs}/Lib/Doctrine/DataFixtures/AbstractBaseFixture.php:123
 {VendorNs}/Lib/Doctrine/DataFixtures/AbstractBaseFixture->findPersistedEntity() at D:/projects/{projectname}/src/ProjectVendor/Bundle/DataFixturesBundle/Classes/ORM/LookupFixture.php:38
 {ProjectNs}/Bundle/DataFixturesBundle/Classes/ORM/LookupFixture->lookupentityDefaultBuilder() at D:/projects/{projectname}/src/ProjectVendor/Bundle/DataFixturesBundle/DataFixtures/ORM/Main/User/LookupData.php:59
 {ProjectNs}/Bundle/DataFixturesBundle/DataFixtures/ORM/Main/User/LookupData->onlinestatusBuild() at n/a:n/a
 call_user_func() at D:/projects/{projectname}/src/ProjectVendor/Bundle/DataFixturesBundle/Classes/ORM/LookupFixture.php:78
 {ProjectNs}/Bundle/DataFixturesBundle/Classes/ORM/LookupFixture->lookupentityDefaultLoader() at D:/projects/{projectname}/src/ProjectVendor/Bundle/DataFixturesBundle/DataFixtures/ORM/Main/User/LookupData.php:42
 {ProjectNs}/Bundle/DataFixturesBundle/DataFixtures/ORM/Main/User/LookupData->load() at D:/projects/{projectname}/vendor/doctrine/data-fixtures/lib/Doctrine/Common/DataFixtures/Executor/AbstractExecutor.php:120
 Doctrine/Common/DataFixtures/Executor/AbstractExecutor->load() at D:/projects/{projectname}/vendor/doctrine/data-fixtures/lib/Doctrine/Common/DataFixtures/Executor/ORMExecutor.php:83
 Doctrine/Common/DataFixtures/Executor/ORMExecutor->Doctrine/Common/DataFixtures/Executor/{closure}() at n/a:n/a
 call_user_func() at D:/projects/{projectname}/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:223
 Doctrine/ORM/EntityManager->transactional() at D:/projects/{projectname}/var/cache/apps/web/local/jms_diextra/doctrine/EntityManager_50ffafed6b09f.php:31
 EntityManager50ffafed6b09f_546a8d27f194334ee012bfe64f629947b07e4919/__CG__/Doctrine/ORM/EntityManager->transactional() at D:/projects/{projectname}/vendor/doctrine/data-fixtures/lib/Doctrine/Common/DataFixtures/Executor/ORMExecutor.php:85
 Doctrine/Common/DataFixtures/Executor/ORMExecutor->execute() at D:/projects/{projectname}/vendor/doctrine/doctrine-fixtures-bundle/Doctrine/Bundle/FixturesBundle/Command/LoadDataFixturesDoctrineCommand.php:106
 Doctrine/Bundle/FixturesBundle/Command/LoadDataFixturesDoctrineCommand->execute() at D:/projects/{projectname}/vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php:238
 Symfony/Component/Console/Command/Command->run() at D:/projects/{projectname}/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:192
 Symfony/Component/Console/Application->doRun() at D:/projects/{projectname}/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:78
 Symfony/Bundle/FrameworkBundle/Console/Application->doRun() at D:/projects/{projectname}/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:105
 Symfony/Component/Console/Application->run() at D:/projects/{projectname}/bin/console.php:17
Comment by Benjamin Eberlei [ 01/May/13 ]

This works in this recent commit here, 0864ab8adac5c31d5ba97f0eb6792e5431a75b70. Should have worked before as well. Can you verify?

Comment by Benjamin Eberlei [ 01/May/13 ]

Related to DDC-1998, tests this behavior





[DDC-2136] convert-mapping can't create YML from Annotation when Id column is a OneToOne relationship Created: 11/Nov/12  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3
Fix Version/s: 2.4

Type: Bug Priority: Minor
Reporter: Gergely Polonkai Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: yaml
Environment:

Symfony 2.1.3



 Description   

I have two entities

/**

  • @ORM\Entity
    */
    class User { /** * @ORM\Id * @ORM\GeneratedValue(strategy="AUTO") * @ORM\Column(type="integer") */ private $id }

/**

  • @ORM\Entity
    */
    class UserData { /** * @ORM\Id * @ORM\OneToOne(targetEntity="User") */ private $id }

When I convert these with symfony's

doctrine:mapping:convert yml test/

it generates an entity definition for UserData without any id fields, which, of course, cannot be imported to the database, as the new entity doesn't have an identifier column.



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

Fixed in 2.4





[DDC-2422] HIDDEN fileds doesn't work in subqueries Created: 29/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.3.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: yetanotherape Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

I trying to execute query with subquery, which contains GROUP BY:

$subqueryBuilder = $repository->createQueryBuilder('l2')
    ->select('l2.id, DATE(l2.created) AS HIDDEN created_date')
    ->groupBy('created_date');

$qb = $repository->createQueryBuilder('l');
$qb->andWhere($qb->expr()->in('l.id', $subqueryBuilder->getDQL()));
$result = $qb->getQuery()->getArrayResult();

And got error:

[Syntax Error] line 0, col 80: Error: Expected Doctrine\ORM\Query\Lexer::T_FROM, got ','

If I group simply by "l2.created" without adding it to selected fields, all works fine. But I must use "DATE(l2.created) AS HIDDEN created_date" in selected statement to specify it in GROUP BY statement.



 Comments   
Comment by Marco Pivetta [ 01/May/13 ]

`HIDDEN` is expected to be used only to handle hydration. Your example is already invalid at SQL level, where it would result in something like:

SELECT
    f.bar
FROM
    foo f
WHERE
    f.id IN(
        SELECT
            b.baz,
            b.tab
        FROM
            bar b
    )

That will obviously fail

Comment by yetanotherape [ 01/May/13 ]

Ok, so how I can do:

SELECT
    f.bar
FROM
    foo f
WHERE
    f.id IN(
        SELECT
            b.id
        FROM
            bar b
        GROUP BY DATE(b.created)
    )

in DQL?

Comment by Marco Pivetta [ 01/May/13 ]

You cannot right now.

That's not supported by all vendors - if you need such a query, use native SQL instead.





[DDC-2370] Subclass annotations not being read, unable to use OneToMany relation with single table inheritance Created: 26/Mar/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Arthur Bodera Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: annotationdriver, inheritance, orm
Environment:

PHP 5.4.11



 Description   

Subclasses that override parent class properties and define relations will not work as expected, because AnnotationDriver/Reader will only use the parent class annotation (discarding whatever subclass defined).

The following code will produce error:

[Mapping]  FAIL - The entity-class 'Test\Office' mapping is invalid:
* The mappings Test\Office#employees and Employee#office are incosistent with each other.

Test code:

<?php
namespace Test;
 
use Doctrine\ORM\Mapping as ORM;
 
/**
 * @ORM\Entity
 */
class Office 
{
    /**
     * @ORM\OneToMany(targetEntity="Person", mappedBy="office")
     * @var Person[]|ArrayCollection
     */
    protected $people;
 
    /**
     * @ORM\OneToMany(targetEntity="Employee", mappedBy="office")
     * @var Employee[]|ArrayCollection
     */
    protected $employees;
 
}
 
/**
 * @ORM\Entity
 * @ORM\InheritanceType("SINGLE_TABLE")
 * @ORM\DiscriminatorColumn(name="type", type="string")
 * @ORM\DiscriminatorMap({"employee" = "Employee"})
 */
class Person
{
    /**
     * @ORM\ManyToOne(targetEntity="Office", inversedBy="people")
     * @var Office
     */
    protected $office;
}
 
/**
 * @ORM\Entity
 */
class Employee extends Person
{
    /**
     * @ORM\ManyToOne(targetEntity="Office", inversedBy="employees")
     * @var Office
     */
    protected $office;
}


 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

Overwriting assocations in this way is not supported.

Comment by Arthur Bodera [ 01/May/13 ]

Ok, I get that it's not supported right now, but why did you mark it as resolved?





[DDC-349] Add support for specifying precedence in joins in DQL Created: 18/Feb/10  Updated: 01/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.0-ALPHA4
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Dennis Verspuij Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 1
Labels: None

Attachments: Text File DDC349Test.patch    
Issue Links:
Duplicate
is duplicated by DDC-1256 Generated SQL error with DQL WITH and... Resolved

 Description   

This request is in followup to my doctrine-user message "Doctrine 2.0: Nested joins'.
I am a bit surprised by the responses in that defining precedences in joins by placing parenthesis around join expressions is not well-known. Although not in the original SQL92 specification it is a major and important feature offered by all the RDBMS's that Doctrine 2 supports, and oftenly performs better than using subselects or alike. Doctrine 1 did not support it, but imho Doctrine 2 should support it to be a mature allround ORM.

As a short example the following is a SQL statement with a nested join, where the nesting is absolutely necessary to return only a's together with either both b's and c's or no b's and c's at all:

SELECT *
FROM a A
LEFT JOIN (
b B
INNER JOIN c C ON C.b_id = B.id
) ON B.a_id = A.id

In order for Doctrine 2 to support this the BNF should be something like:
Join ::= ["LEFT" ["OUTER"] | "INNER"] "JOIN" ( "(" JoinAssociationPathExpression ["AS"] AliasIdentificationVariable Join ")" | JoinAssociationPathExpression ["AS"] AliasIdentificationVariable ) [("ON" | "WITH") ConditionalExpression]
instead of the current:
Join ::= ["LEFT" ["OUTER"] | "INNER"] "JOIN" JoinAssociationPathExpression ["AS"] AliasIdentificationVariable [("ON" | "WITH") ConditionalExpression]

This would allow DQL like:

SELECT A, B, C
FROM a A
LEFT JOIN (
A.b B
INNER JOIN B.c C
) WITH B.something = 'value' AND C.something = 'othervalue'

What further needs to be done is that the DQL parser loosly couples the ConditionalExpression to any of the previously parsed JoinAssociationPathExpression's instead of tieing it explicitely to the JoinAssociationPathExpression that preceedes it according to the old BNF notation. The new BNF should however not require any changes to the hydrator. Therefore I have the feeling that improving the DQL parser for nested joins does not require extensive work, while the benefit of running these kind of queries is considerable.

As an extra substantiation here are links to (BNF) FROM clause documentations of the RDBMS's that Doctrine 2 supports, they all show support for nested joins:
MySQL: http://dev.mysql.com/doc/refman/5.0/en/join.html
PostgreSQL: http://www.postgresql.org/docs/8.4/interactive/sql-select.html#SQL-FROM and http://www.postgresql.org/docs/8.1/interactive/explicit-joins.html
MSSQL: http://msdn.microsoft.com/en-us/library/ms177634.aspx
Oracle: http://download.oracle.com/docs/cd/E11882_01/server.112/e10592/statements_10002.htm#CHDDCHGF
SQLite: http://www.sqlite.org/syntaxdiagrams.html#single-source

I surely hope you will consider implementing this improvement because it would save me and others from the hassle of writing raw SQL queries or executing multiple (thus slow) queries in DQL for doing the same. Thanks anyway for the great product so far!



 Comments   
Comment by Guilherme Blanco [ 13/Apr/10 ]

This seems to be a valid issue to me.

This implementation is the actual solution to associations retrieval that are inherited (type joined).

Example:

/** Joined */
class Base {}

class Foo extends Base {}

class Bar {
    public $foo;
}

// This causes the CTI to link as INNER JOIN, which makes the result become 0
// il if you have no Foo's defined (although it should ignore this)
$q = $this->_em->createQuery('SELECT b, f FROM Bar b LEFT JOIN b.foo f'); 
Comment by Roman S. Borschel [ 13/Apr/10 ]

Yes, this is a possible solution for DDC-512 but on the SQL level. I still don't see this as appropriate for DQL, it just doesnt make sense to me, DQL joins object associations, there is no precedence.

Comment by Roman S. Borschel [ 13/Apr/10 ]

So, no, this has nothing to do with DDC-512. DDC-512 can even be fixed differently as outlined in my comments there.

Comment by Roman S. Borschel [ 13/Apr/10 ]

On a side note I would still like to know/see the following for this issue:

  • Some realisitic DQL examples where this feature would be essential, i.e. there is no other way to do it.
    This also means explaining what the impact on the resulting object graph is and why it makes sense.
  • Which other ORMs support this on the OQL/Criteria level?

So far, my stance on this issue is:

1) It doesnt make sense (semantically) in DQL
2) Its rarely needed
3) When you really need it you can use a NativeQuery anyway and use this nesting in SQL, where it probably belongs and makes more sense
4) It would (unnecessarily) complicate DQL

Thus I am currently leaning towards "Wont fix" for this issue.

Comment by Dennis Verspuij [ 13/Apr/10 ]

Hi Roman. I understand your doubts, and I have been breaking my head over
creating a realistic example the last few hours that would hopefully convince
you for implementing this feature. But actually I cannot find one that you wouldn't
consider to be trivial. I do have a number of very complex optimized queries written
for sportskickoff dot com (using Doctrine 1.2) but they are probably hard to understand
because they may not be selfdescribing. Below is one example literally ripped from
the application. Still they often can be broken down to my example query in this
ticket's description, but applied grouping, additional other joins on the root component
and/or other criteria made them impossible to rewrite using subselects or choosing
another root component. Most often they just performed way best using the nested
syntax and saved me a number of additional queries.

SELECT A.id, A.username, A.balance, COALESCE(SUM(B.stake), 0) AS sumstake, COUNT(B.id) AS nrbets
FROM account A
LEFT JOIN (
bet B
INNER JOIN game G ON G.id = :GAMEID AND B.timestampcompletion BETWEEN G.timestampstart AND G.timestampend
) ON B.accountid = A.id AND B.timestampcompletion IS NOT NULL
WHERE A.Status & :ACTIVEORDISQUALIFIED = :ACTIVE
GROUP BY A.id, A.username, A.balance
ORDER BY A.balance DESC, sumstake ASC, nrbets ASC, A.username ASC

But let's put it another way. I would also like this feature to be supported in DQL
because I just do not want to use native queries. Why would I want to use native
queries if it can be done using DQL? In DQL I work with class names and field
names, and they may differ from the underlying table and column names. Doctrine
takes care of that mapping based on my schema/annotations and I do not
have to "know" these mappings. In native queries I suddenly do have to "know"
these mappings. I use Doctrine because it makes my application portable and
enables me to work with my database in an OOP way like I do in my model,
abstracting things. The need for native queries partly reverts the benefits Doctrine
offers in the first place.

Btw, I recall to have successfully used the nested join syntax in HQL (.NET Hibernate)
but I cannot find examples on the web or a BNF notation.

Furthermore, in reply to your stances:
1) It indeed doesnt make sense (semantically) in DQL, it only makes the result
set different, but not the way data is hydrated into objects;
2) Its indeed rarely needed for inserting, updating and populating basic lists but
it allows you to better select what combinations of associated rows are joined
and which not in more optimized queries without having to use native queries,
or because they perform better than using subseletcs and alike.
3) Not having to use native queries is just an extra reason for using Doctrine and
maintains the abstraction the ORM provides througout on'es whole application
4) Why would it complicate DQL, if people do not know about or understand
the feature it wouldn't matter because not using parenthesises is the default
way to specify joins?

Well, this is it, can't find any more words to promote and make you enthusiastic.... lol.

Comment by Dennis Verspuij [ 13/Apr/10 ]

Ok, I have not given up yet... , here's a "stupid" example.

Imagine a book store that sells books of various authors and keeps track of those sales.
Let's say you would have an admin page that lists all authors, and for each author
its also shows the books and their sales dates since january 1st, but only for those
books that were actually sold and contain an A in its name. An optimized SQL query
to fetch all the information at once would be something like:

SELECT A., B., S.*
FROM author A
LEFT JOIN (
book B
INNER JOIN sale S ON S.book_id = B.id AND S.dt >= '2010-01-01'
) ON B.author_id = A.id AND A.name LIKE '%A%'

In DQL it would then be something like:

SELECT A., B., S.*
FROM author A
LEFT JOIN (
book B
INNER JOIN sale S WITH S.dt >= '2010-01-01'
) WITH A.name LIKE '%A%'

If the database would contain thousands of books, but sales for just a
few books, this will definitely perform better than using subselects.
Off course one would like to fetch array graphs instead of objects for
further optimization, but this hopefully shows my point.

I have attached a test casefor a similar query, though without the additional
join constraints for clarity. I surely hope you can consider it.

One last note, you shouldn't be afraid that nesting joins is not in the
ansi SQL spec. Select queries are about record sets and products
between these sets, tables are just the basic means of providing record
sets to the query. This is an important terminological difference to think about.
Specifying precedence with parenthesis around joins is a logical and
natural evolution of the ansi sql standard. For example views are a good
proof of this concept, I could define book B INNER JOIN sale S as a view
and LEFT JOIN that to authors to get effectively the same result
set as the above example. The database server would internally perform the
same query (though may additionally take indexes on the view into account).
That said, rdbm's that support this syntax would certainly never drop the
feature, as its not a feature but just plain logical and smart querying!

P.S. I had a hard time finding out how to run the test cases, I could not find
it in the Doctrine 2 documentation, development wiki, cookbook or any other
place, while finally it was as easy as running phpunit Doctrine_Tests_AllTests
from within the tests/ directory, or just phpunit Doctrine_Tests_ORM_Functional_Ticket_DDC349Test
for my test. Could you please add some info about this somewhere, it might
save others some googling.

Comment by Dennis Verspuij [ 13/Apr/10 ]

Test case as SVN patch using a parenthesized join.
Just remove the parenthesises from the query to have it fail...

Comment by Roman S. Borschel [ 29/May/10 ]

@"The need for native queries partly reverts the benefits Doctrine offers in the first place."

That is something I hugely disagree with. Neither SQL abstraction, nor database vendor independence is the main purpose of an ORM like Doctrine 2.
It is the state management of your objects, the transparent change tracking, lazy-loading and synchronization of the object state with the database state and nothing of this gets lost when using native queries.

We could rip out DQL and any other querying mechanism except a basic find() (and lazy-loading, of course), only providing the native query facility and even only supporting MySQL and would still retain all the core ORM functionality.

NativeQuery is one of the best and core "features" of the project. It is even the foundation for DQL. A DQL query is nothing more than an additional (beautiful) abstraction but what comes out is a native query + a ResultSetMapping, the same thing you can build yourself in the first place, even using the mapping metadata to construct the query. Nothing forces you to hardcode table and column names in native queries if you don't want that. Just use the mapping metadata, DQL does the same.

SQL abstraction and database vendor independence is icing on the cake, not the heart of the ORM.





[DDC-1256] Generated SQL error with DQL WITH and JOINED inheritance Created: 06/Jul/11  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.0.3, 2.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Justin Hendrickson Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 1
Labels: None
Environment:

Ubuntu 11.04


Issue Links:
Duplicate
duplicates DDC-349 Add support for specifying precedence... Open
is duplicated by DDC-2131 Fetch join not working on class table... Resolved

 Description   

I've created an entity that has a one to one relationship to a class in an inheritance tree and I'm using class table inheritance in Doctrine. When I try to add a DQL WITH statement on a column in the super class to the join, the generated SQL incorrectly places the statement in the child classes JOIN ON section.

Here's the DQL:

SELECT p FROM Fampus_Entity_Photo p LEFT JOIN p.flag f WITH f.status='ok'

Here's the generated SQL:

SELECT p0_.id AS id0, p0_.name AS name1, p0_.path AS path2, p0_.type AS type3, p0_.reference_id AS reference_id4, p0_.view_count AS view_count5, p0_.created AS created6, p0_.modified AS modified7, p0_.event_id AS event_id8, p0_.user_id AS user_id9, p0_.school_id AS school_id10, p0_.flag_id AS flag_id11 FROM photos p0_ LEFT JOIN flaggedcontent_photo f1_ ON p0_.flag_id = f1_.id AND (f2_.status = 'ok') LEFT JOIN flaggedcontent f2_ ON f1_.id = f2_.id

Note that f2_.status = 'ok' is the correct statement, but it is in the wrong LEFT JOIN ON section.

Here are my entities (significantly clipped):

/**
 * @Table(name="photos")
*/
class Photo {
    /**
     * @OneToOne(targetEntity="FlaggedContent_Photo", mappedBy="photo")
     * @JoinColumn(nullable=true)
     */
    protected $flag;
}

/**
 * @DiscriminatorColumn(name="type")
 * @DiscriminatorMap({
 *     "photo" = "FlaggedContent_Photo"
 * })
 * @InheritanceType("JOINED")
 * @Table(name="flaggedcontent")
*/
abstract class FlaggedContent {
    /**
     * Database identifier
     *
     * @Id
     * @Column(type="integer")
     * @GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * Status
     *
     * @Column(type="text")
     * @var string
     */
    protected $status;
}

/**
 * @Entity
 * @Table(name="flaggedcontent_photo")
 */
class FlaggedContent_Photo extends FlaggedContent {
    /**
     * @OneToOne(targetEntity="Photo", inversedBy="flag")
     */
    protected $photo;
}


 Comments   
Comment by Michael Ridgway [ 06/Jul/11 ]

I created a test for this: https://github.com/mridgway/doctrine2/commit/1bb26a46188f180270d723e395ee707443ebdda1

I'll see if I can figure this out.

Comment by Michael Ridgway [ 11/Jul/11 ]

It doesn't seem that you would get the correct result if the WITH statement was on the 'flaggedcontent' table anyway. In order for this to work, the query would have to join 'flaggedcontent' first and then join to 'flaggedcontent_photo' based on f2_.id. While we can probably (but not easily) fix where the condition is placed, I don't think this will ever be able to give the expected results for ALL cases.

Comment by Benjamin Eberlei [ 12/Jul/11 ]

Formatting

Comment by Benjamin Eberlei [ 12/Jul/11 ]

This issue is unfixable, we tend towards throwing an exception in this case to notify developers that they cannot do this.

The only way to make it work is to move the status check to the WHERE clause.

Comment by Guilherme Blanco [ 14/Aug/11 ]

This issue is fixable by applying what we call as nested joins when generating the SQL.

This issue report #DDC-349 (http://www.doctrine-project.org/jira/browse/DDC-349) suggest us to support it in DQL, but I think we can introduce this generation on SQL only.
It's not a trivial implementation, but it would solve a couple of other issue I was looking into.

Cheers,

Comment by Benjamin Eberlei [ 01/May/13 ]

Duplicate of DDC-349





[DDC-1318] Unexpectet behavior while using ManyToOne as part ofr composite key Created: 04/Aug/11  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: 2.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Peter Jasiulewicz Assignee: Benjamin Eberlei
Resolution: Incomplete Votes: 0
Labels: None
Environment:

ubuntu 64x



 Description   

Hi!

Ran into a problem while wanted to use a ManyToOne as part of a primary key:

 * @Entity
 * @Table(name="user_preferences")
  */
class UserPreferences  {

    /**
     * @Id
     * @ManyToOne(targetEntity="User",cascade={"persist"})
     *  @JoinColumn(name="user_id", referencedColumnName="id")
     */
    protected $user;
    /**
     * @Id
     * @GeneratedValue(strategy="NONE")
     * @Column(name="preference_id",type="smallint",nullable=false)
     */
    protected $preference_id;

By default doctrine creates a table with 2 single keys (the preference key is the primary key) which is of course incorrect.
Had to add @Column(name="user_id",type="integer") to the user column to fix the index problem but that introduced another problem. The entity no longer accepter \Entity\User as a value for user and takes only a smallint as defined.



 Comments   
Comment by Benjamin Eberlei [ 04/Aug/11 ]

This is probably because of the @GeneratedStrategy annotation, can you try to just remove it? For me there is always only one key generated.

Comment by Peter Jasiulewicz [ 04/Aug/11 ]

Hi,
thanks fo the fast reply

     * @Id
     * @ManyToOne(targetEntity="User",cascade={"persist"})
     *  @JoinColumn(name="user_id", referencedColumnName="id")
     */
    protected $user;

     * 
     * @Id
     * @Column(name="preference_id",type="smallint",nullable=false)
     */
    protected $preference_id;

On MySQL creates:

mysql> show indexes from xxx.user_preferences;
+------------------+------------+------------------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
| Table            | Non_unique | Key_name                     | Seq_in_index | Column_name   | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+------------------+------------+------------------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
| user_preferences |          0 | PRIMARY                      |            1 | preference_id | A         |           0 |     NULL | NULL   |      | BTREE      |         |
| user_preferences |          1 | user_preferences_user_id_idx |            1 | user_id       | A         |           0 |     NULL | NULL   | YES  | BTREE      |         |
+------------------+------------+------------------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
2 rows in set (0.01 sec)

With:

     * @Id
     * @ManyToOne(targetEntity="User",cascade={"persist"})
     *  @JoinColumn(name="user_id", referencedColumnName="id")
     * @Column(name="user_id",type="integer")
     */
    protected $user;
 
     
     * @Id
     * @GeneratedValue(strategy="NONE")
     * @Column(name="preference_id",type="smallint",nullable=false)
     */
    protected $preference_id;

Creates:

mysql> show indexes from xxx.user_preferences;
+------------------+------------+----------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
| Table            | Non_unique | Key_name | Seq_in_index | Column_name   | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+------------------+------------+----------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
| user_preferences |          0 | PRIMARY  |            1 | user_id       | A         |           0 |     NULL | NULL   |      | BTREE      |         |
| user_preferences |          0 | PRIMARY  |            2 | preference_id | A         |           0 |     NULL | NULL   |      | BTREE      |         |
+------------------+------------+----------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
2 rows in set (0.00 sec)

The annotations:

     * @Id
     * @ManyToOne(targetEntity="User",cascade={"persist"})
     *  @JoinColumn(name="user_id", referencedColumnName="id")
     */
    protected $user;

     * @Id
     * @Column(name="preference_id",type="smallint",nullable=false)
     */
    protected $preference_id;

Create the same effect like the first one:

mysql> show indexes from xxx.user_preferences;
+------------------+------------+------------------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
| Table            | Non_unique | Key_name                     | Seq_in_index | Column_name   | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+------------------+------------+------------------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
| user_preferences |          0 | PRIMARY                      |            1 | preference_id | A         |           0 |     NULL | NULL   |      | BTREE      |         |
| user_preferences |          1 | user_preferences_user_id_idx |            1 | user_id       | A         |           0 |     NULL | NULL   | YES  | BTREE      |         |
+------------------+------------+------------------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
2 rows in set (0.00 sec)

Sequence of events :
1) change in annotations in entity object
2) dropped the table affected
3) orm:schema-tool:update --force

Comment by Benjamin Eberlei [ 06/Aug/11 ]

Formatted code.

Comment by Benjamin Eberlei [ 06/Aug/11 ]

Can you drop the table and show the DDL generated by both "orm:schema-tool:create --dump-sql" and "orm:schema-tool:update --dump-sql" ?

I checked with our testsuite and all the entities generate the correct primary keys.

Comment by Marco Pivetta [ 23/Jan/13 ]

Is this still valid with newer versions of the ORM?

Comment by Benjamin Eberlei [ 01/May/13 ]

No feedback given





[DDC-1816] DiscriminatorColumn Metadata wrong Created: 08/May/12  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: 2.2.1, 2.2.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Florian Schmedding Assignee: Benjamin Eberlei
Resolution: Incomplete Votes: 0
Labels: None
Environment:

Windows 7, PHP 5.38



 Description   

The discriminator column metadata (inheritance) is not properly processed. For example, using an entity described by XML annotations containing

<discriminiator-column name="category" type="string" length="30"/>

will generate wrong SQL queries containing the column 'dtype' instead of 'category' when using an XML metadata driver.
Generating classes from the XML metadata with

doctrine orm:generate-entities --generate-annotations="true" --generate-methods="true"  entities

produces wrong docblock annotations like

@ORM\DiscriminatorColumn(name="r", type="r", length=r)

However, the entity works as expected after correcting the annotation values and replacing the XML meatdata driver by an annotation metadata driver.



 Comments   
Comment by Benjamin Eberlei [ 08/Jul/12 ]

It works for me https://github.com/doctrine/doctrine2/commit/7b758eee573a2667fccfe72dabacf3639c960911

Can you post your XML mapping that produces this behavior?

Comment by Benjamin Eberlei [ 01/May/13 ]

No feedback given





[DDC-1998] Problem when deleting with EntityManager->remove($entity) Created: 28/Aug/12  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.2.3
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Minor
Reporter: victor Velkov Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Attachments: File DDC1998Test.php     File DDC1998Test1.php     File EwtTimestamp.php     File ProductTemplate.php    

 Description   

The problem is when using EntityMamager->remove($entity). The Sql query generated doesn't convert the values of the ids according to the field type that is used in doc block annotation. After investigating I found that in Doctrine\DBAL\Connection the function delete doesn't support to receive as param the types of the ids to be given to the executeUpdate function which is called in it and supports them. (The types need to be provided from the persisters from which the delete is called).

I hope it make sense to you. I got that problem because I am using custom time stamp column type as id. And it converts the value of the field to time stamp string, which if not converted to the proper sql value is not recognised and the delete doesn't go trough.

As far as I can see it is something that was missed and hope it will be fixed soon.

If you have any questions please ask.
Also on request I can provide example code and the fix I have done for myself.



 Comments   
Comment by Fabio B. Silva [ 29/Aug/12 ]

Hi Victor

Could you attach/paste your custom type and entity please ?

Comment by victor Velkov [ 30/Aug/12 ]

Ok I have attached them. The EwtTimestamp is the custom type.

Comment by Marco Pivetta [ 17/Sep/12 ]

victor Velkov do you have a failing test case for this one?

Comment by victor Velkov [ 17/Sep/12 ]

Nope sorry haven't done any test cases for this one

Comment by Fabio B. Silva [ 23/Sep/12 ]

Hi Victor,

I can't reproduce, could you change the added test case and try to make it fails ?

Thanks

Comment by victor Velkov [ 26/Sep/12 ]

Sure will do it as soon as I can. Sorry I didn't answer sooner just was in a holiday

Comment by Fabio B. Silva [ 02/Oct/12 ]

Thanks Victor

Please let me know when you change the test

Comment by victor Velkov [ 02/Oct/12 ]

Sorry for the delay i have attached the test case (DDC1998Test1.php).

Comment by Fabio B. Silva [ 10/Oct/12 ]

Hi Victor,

Sorry for the delay to answer

I think that we can't fix it,
Your type requires sql conversion to work, and doctrine does not support @Id fields with sql conversion.

Comment by victor Velkov [ 11/Oct/12 ]

Really as far as i can see in the code you do convert them when you are executing an update. And the fix that i did for my self is to add 3rd parameter to the function delete in Doctrine\DBAL\Connection and then every where where it is called in the code which is in 2 places Doctrine\ORM\Persisters\BasicEntityPersister and Doctrine\ORM\JoinedSubclassPersister to give that parameter with the types. And as far as i can see you do that for the updates. After that in Connection delete you call the executeUpdate which supports the type and you just have to pass it along. And that is it.

Comment by Marco Pivetta [ 23/Jan/13 ]

Reducing priority. It is an edge case, and we already don't officially support custom object types as identifiers.

Comment by Benjamin Eberlei [ 01/May/13 ]

We should be able to support this I think, i don't see a reason it shouldnt work

Comment by Benjamin Eberlei [ 01/May/13 ]

Will be fixed in 2.4





[DDC-2413] orm:schema-tool:update want to drop&create PK on join table using composite keys Created: 25/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, Tools
Affects Version/s: Git Master, 2.3.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Bruno CHALOPIN Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: composite
Environment:

Ubuntu 12.04, php 5.4.9



 Description   

Given these entities :

/**
 * Class Domain
 *
 * @Entity
 * @Table(name="profils_domains")
 */
class Domain
{
    /**
     * @var string
     *
     * @Id
     * @Column(type="string", length=22, nullable=false)
     */
    protected $name = '';
}
/**
 * Class User
 *
 * @Entity
 * @Table(name="profils_users")
 */
class User
{
    /**
     * @var string
     *
     * @Id
     * @Column(type="string", length=22, nullable=false)
     */
    protected $name = '';

    /**
     * @var Domain
     *
     * @Id
     * @ManyToOne(targetEntity="Domain", fetch="LAZY")
     * @JoinColumn(name="domain", referencedColumnName="name", onDelete="CASCADE")
     */
    protected $domain;
    
    /**
     * @var Group[]|ArrayCollection
     *
     * @ManyToMany(targetEntity="Group", mappedBy="users")
     */
    protected $groups;
}
/**
 * Class Group
 *
 * @Entity
 * @Table(name="profils_groups")
 */
class Group
{
    /**
     * @var string
     *
     * @Id
     * @Column(type="string", length=22, nullable=false)
     */
    protected $name = '';

    /**
     * @var Domain
     *
     * @Id
     * @ManyToOne(targetEntity="Domain", fetch="LAZY")
     * @JoinColumn(name="domain", referencedColumnName="name", onDelete="CASCADE")
     */
    protected $domain;
    
    /**
     * @var User[]|ArrayCollection
     *
     * @ManyToMany(targetEntity="User", indexBy="name", fetch="EXTRA_LAZY")
     * @JoinTable(name="profils_groups_users",
     *      joinColumns={
     * @JoinColumn(name="group_name", referencedColumnName="name", onDelete="CASCADE"),
     * @JoinColumn(name="domain", referencedColumnName="domain", onDelete="CASCADE")
     *          },
     *      inverseJoinColumns={
     * @JoinColumn(name="user_name", referencedColumnName="name", onDelete="CASCADE"),
     * @JoinColumn(name="domain", referencedColumnName="domain", onDelete="CASCADE")
     *          }
     *      )
     */
    protected $users;
}

I want to link users and groups but only from the same domain.

orm:schema-tool:create generate correct SQL :

CREATE TABLE profils_users (name VARCHAR(22) NOT NULL, domain VARCHAR(22) NOT NULL, INDEX IDX_E75993CFA7A91E0B (domain), PRIMARY KEY(name, domain)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;
CREATE TABLE profils_domains (name VARCHAR(22) NOT NULL, PRIMARY KEY(name)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;
CREATE TABLE profils_groups (name VARCHAR(22) NOT NULL, domain VARCHAR(22) NOT NULL, INDEX IDX_229366BBA7A91E0B (domain), PRIMARY KEY(name, domain)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;
CREATE TABLE profils_groups_users (group_name VARCHAR(22) NOT NULL, domain VARCHAR(22) NOT NULL, user_name VARCHAR(22) NOT NULL, INDEX IDX_6CF8F4EA77792576A7A91E0B (group_name, domain), INDEX IDX_6CF8F4EA24A232CFA7A91E0B (user_name, domain), PRIMARY KEY(group_name, domain, user_name)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;
ALTER TABLE profils_users ADD CONSTRAINT FK_E75993CFA7A91E0B FOREIGN KEY (domain) REFERENCES profils_domains (name) ON DELETE CASCADE;
ALTER TABLE profils_groups ADD CONSTRAINT FK_229366BBA7A91E0B FOREIGN KEY (domain) REFERENCES profils_domains (name) ON DELETE CASCADE;
ALTER TABLE profils_groups_users ADD CONSTRAINT FK_6CF8F4EA77792576A7A91E0B FOREIGN KEY (group_name, domain) REFERENCES profils_groups (name, domain) ON DELETE CASCADE;
ALTER TABLE profils_groups_users ADD CONSTRAINT FK_6CF8F4EA24A232CFA7A91E0B FOREIGN KEY (user_name, domain) REFERENCES profils_users (name, domain) ON DELETE CASCADE

but I make a orm:schema-too:update it want to drop and recreate the PK of the join table each time, and with a wrong sql query :

ALTER TABLE profils_groups_users DROP PRIMARY KEY;
ALTER TABLE profils_groups_users ADD PRIMARY KEY (group_name, domain, user_name, domain)

To avoid the duplication of the same field in primary key creation, you can modify getIndexFieldDeclarationListSQL from Doctrine\DBAL\Platforms\AbstractPlatform like :

    public function getIndexFieldDeclarationListSQL(array $fields)
    {
        $ret = array();

        foreach ($fields as $field => $definition) {
            if (is_array($definition)) {
                $ret[$field] = true;
            } else {
                $ret[$definition] = true;
            }
        }
        $ret = array_keys($ret);

        return implode(', ', $ret);
    }

But it would also be nice that doctrine don't try to drop the PK on each update.



 Comments   
Comment by Marco Pivetta [ 25/Apr/13 ]

Bruno CHALOPIN do I get this right if I say it's a problem in how columns are sorted in the index definition? Is that the problem?

Comment by Bruno CHALOPIN [ 25/Apr/13 ]

I don't think it is a sort order problem (that is to say, i don't care the order).

Firstable I don't know why it want to delete the PK as the generation of the join table is correct.
Secondly, the regeneration of the PK is clearly buggy as it use 2 times the domain field.

Comment by Bruno CHALOPIN [ 25/Apr/13 ]

It's even worse than I thought. When persisting new users, it create this SQL query :

INSERT INTO profils_groups_users (group_name, domain, user_name, domain) VALUES (?, ?, ?, ?)

I've made a quick fix by adding $columns = array_keys(array_flip($columns)); before the return in Doctrine\ORM\Persisters\ManyToManyPersister::_getInsertRowSQL and $mapping['joinTableColumns'] = array_keys(array_flip($mapping['joinTableColumns'])); before the foreach in Doctrine\ORM\Persisters\ManyToManyPersister::_collectJoinTableColumnParameters

It works but I don't know if it's a proper solution.

Comment by Benjamin Eberlei [ 01/May/13 ]

You are thinking wrong here, domain can be present in the many to many table twice, with different domains. That you don't have this use-case, because you know the constraint to be 1:1 doesn't matter to Doctrine.

It only works with you having a domain_user and a domain_group column, and then it will work in the ManyToManyPersister and in the SchemaTool Update

Comment by Bruno CHALOPIN [ 01/May/13 ]

With a domain_user and a domain_group you can no longer be sure that a user can only be in groups from the same domain which is mandatory for me. That's why I don't want the domain to be here twice as it must be the same for the user and the group.

Comment by Benjamin Eberlei [ 01/May/13 ]

Yes, this kind of normalization is not supported by Doctrine. You can enforce this with a CHECK constraint or in your domain code.

Comment by Bruno CHALOPIN [ 01/May/13 ]

I know this kind of normalization is not supported by Doctrine. That's why I've made a PR (which doesn't introduce any BC breaks). I don't see why it wouldn't be introduce in Doctrine as it's way simpler that adding a CHECK constraint (which I don't find any trace in the annotation documentation)

Comment by Bruno CHALOPIN [ 01/May/13 ]

From the mysql documentation : The CHECK clause is parsed but ignored by all storage engines
So there's no other ways to have a consistent database than to include this functionality in Doctrine.





[DDC-2345] convertObjectParameterToScalarValue() raises a notice Created: 12/Mar/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3
Fix Version/s: 2.4

Type: Bug Priority: Minor
Reporter: Massimiliano Arione Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

In Doctrine\ORM\AbstractQuery.php, the method convertObjectParameterToScalarValue() can raise a Notice.
This code:

$value = $values[$class->getSingleIdentifierFieldName()];

should be changed in this one:

if (isset($values[$class->getSingleIdentifierFieldName()])) {
    $value = $values[$class->getSingleIdentifierFieldName()];
}


 Comments   
Comment by Marco Pivetta [ 12/Mar/13 ]

Massimiliano Arione the current DQL implementation doesn't allow you to bind composite key identifiers as parameters, thus you will never reach that piece of code.

A test would be needed for this case.

Comment by Massimiliano Arione [ 12/Mar/13 ]

Unfortunately, I'm not really a Doctrine guru.
I can tell you that I'm getting that notice, using Sortable behavior with Symfony2.
This is a partial error stack:

1 in (...)/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php at line 282

2 at ErrorHandler ->handle ('8', 'Undefined index: id', '(...)/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php', '282', array('value' => object(MyEntity), 'class' => object(ClassMetadata), 'values' => array()))

3 in (...)/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php at line 282
at AbstractQuery ->convertObjectParameterToScalarValue (object(MyEntity))

4 in (...)/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php at line 260
at AbstractQuery ->processParameterValue (object(MyEntity))

5 in (...)/vendor/doctrine/orm/lib/Doctrine/ORM/Query.php at line 285
at Query ->processParameterMappings (array('group__1' => array('0')))

6 in (...)/vendor/doctrine/orm/lib/Doctrine/ORM/Query.php at line 258
at Query ->_doExecute ()

7 in (...)/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php at line 737
at AbstractQuery ->execute (null, '1')

8 in (...)/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php at line 538
at AbstractQuery ->getResult ()

9 in (...)/vendor/gedmo/doctrine-extensions/lib/Gedmo/Sortable/SortableListener.php at line 410
at SortableListener ->getMaxPosition (object(EntityManager), object(ClassMetadata), array('position' => 'rank', 'groups' => array('my_entity'), 'useObjectClass' => 'Meeting\GestioneBundle\Entity\MyRelatedEntity'), object(MyRelatedEntity))

10 in (...)/vendor/gedmo/doctrine-extensions/lib/Gedmo/Sortable/SortableListener.php at line 114
at SortableListener ->prePersist (object(LifecycleEventArgs))

11 in (...)/vendor/symfony/symfony/src/Symfony/Bridge/Doctrine/ContainerAwareEventManager.php at line 61
Comment by Marco Pivetta [ 12/Mar/13 ]

Massimiliano Arione having a composite primary key?

Comment by Massimiliano Arione [ 12/Mar/13 ]

Nope, just a plain "id".

Comment by Benjamin Eberlei [ 01/May/13 ]

Fixed in 2.4





[DDC-1782] orm:schema-tool:update always produces the SQL to create the database schema and not the needed to update it Created: 17/Apr/12  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2.1, 2.2.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Jordi Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None
Environment:

Ubuntu 11.10, PostgreSQL 9.1, PHP 5.3



 Description   

Tables created by SchemaTool#getSchemaFromMetadata and PostgreSqlSchemaManager#createSchema return different names using the getShortestName function. So, when SchemaTool#getUpdateSchemaSql compares the two schemas all tables are detected as new.



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

Duplicate of DBAL-483





[DDC-1984] ORM tries to fetch an already deleted versioned entity and fails with spl_object_hash error Created: 15/Aug/12  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2.2
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Major
Reporter: Jaco Stienstra Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This is a nasty bug, it doesn't always happen, and i can't seem to reproduce it consistently.

It sometimes happens when trying to fetch a versioned entity which doesn't exist anymore in the database.

Setup:
PHP 5.4.5
PostgreSQL 9.1
Doctrine 2.2.2 with array cache, XML mapping driver

Entity config: BaseEntity mapped as mapped-superclass, User entity extending the base entity:

Mapping file:

<mapped-superclass name="Specula\Entities\BaseEntity">

<field name="updatedOn" type="datetime" column="updated_on" />
<field name="version" version="true" type="integer" column="version" />

<many-to-one field="updatedBy" target-entity="User">
<join-column name="updated_by" referenced-column-name="user_id" />
</many-to-one>

</mapped-superclass>

User entity:

<entity name="Specula\Entities\User" table="users">
<id name="id" type="integer" column="user_id">
<generator strategy="AUTO" />
</id>

<field name="userName" type="string" column="username" length="20" />
<field name="passwordHash" type="string" column="password_hash" length="40" />
<field name="fullName" type="string" column="fullname" length="45" />
<field name="isAdmin" type="boolean" column="is_admin" />
<field name="isActive" type="boolean" column="is_active" />

</entity>

Relevant part of stack trace:

PHP Error [2]

spl_object_hash() expects parameter 1 to be object, null given (/var/www/html/repository/Doctrine/ORM/UnitOfWork.php:1318)

#0 unknown(0): CWebApplication->handleError()
#1 /var/www/html/repository/Doctrine/ORM/UnitOfWork.php(1318): spl_object_hash()
#2 /var/www/html/repository/Doctrine/ORM/UnitOfWork.php(2141): Doctrine\ORM\UnitOfWork->getEntityState()
#3 /var/www/html/repository/Doctrine/ORM/EntityRepository.php(145): Doctrine\ORM\UnitOfWork->lock()
#4 /var/www/html/repository/Doctrine/ORM/EntityManager.php(371): Doctrine\ORM\EntityRepository->find()
#5 /var/www/html/repository/Specula/Dao/BaseDao.php(103): Doctrine\ORM\EntityManager->find()
#6 /var/www/html/repository/Specula/Dao/UserDao.php(33): Specula\Dao\UserDao->findEntityById()
#7 /var/www/html/repository/Specula/Managers/UserManager.php(91): Specula\Dao\UserDao->findById()
#8 /var/www/html/repository/Doctrine/ORM/EntityManager.php(220): Specula\Managers\UserManager->Specula\Managers{closure}()
#9 /var/www/html/repository/Specula/Managers/UserManager.php(93): Doctrine\ORM\EntityManager->transactional()

Deleting the proxy, restarting webserver, restarting database server doesn't help. i'm using the array cache and apc is disabled.

If you need more information let me know i'm currently experiencing this bug so i can provide more information.

Best regards,

Jaco



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

Fixed in 2.3.4





[DDC-2020] [GH-440] The schema tool now doesn't add a foreign constraint when subclassess of... Created: 08/Sep/12  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of sroddy:

Url: https://github.com/doctrine/doctrine2/pull/440

Message:

... a STI use the same field to map relations with entities of different classes

It seems that there are no particular side-effects in mapping different relationship using the same table column name in different subclasses of a STI hierarchy.
Eg. Tag superclass of BookTag (id, object_id, comment) and MovieTag (id, object_id, comment), so having two attributes $book and $movie mapped to the same object_id field with @JoinColumn annotation

I wasn't sure about this so I tested to see if there were errors. And I was surprised that everything runs without any particular problem.
Moreover this is a really interesting (wanted? unwanted?) feature, very useful if you have huge tables that need to be joined with other table using the discriminator and object_id columns, or if you have some kind of logging class and you need to keep the table efficient and small. The only problem is that the schema generator always inserts a foreign column constraint (probably the last specified) when generating these kind of Entities.

This PR ensures that the foreign key is not added if there are at least two different classes mapped on the same field of a db table.






[DDC-2309] Invalid behaviour to flush only one entity Created: 21/Feb/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2, 2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Martin Hasoň Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-2267 EntityManager throws an exception whe... Resolved

 Description   

Current implementation of $em->flush($entity):

  • does not flush entity scheduled for delete
  • flush all entities scheduled for insert

http://www.doctrine-project.org/jira/browse/DDC-720



 Comments   
Comment by Benjamin Eberlei [ 14/Mar/13 ]

The second point is documented, the first point i don't understand, can you elaborate?

Comment by Benjamin Eberlei [ 01/May/13 ]

Duplicate of DDC-2267





[DDC-2106] Notice trying to match a Criteria referencing a managed entity not yet persisted Created: 29/Oct/12  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Minor
Reporter: Francesc Rosàs Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   
Undefined index: (...) in Doctrine/ORM/UnitOfWork.php line 2735

#0 doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php(2735): Symfony\Component\HttpKernel\Debug\ErrorHandler->handle(8, 'Undefined index...', '/Users/frosas/S...', 2735, Array) 
#1 doctrine/orm/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php(1696): Doctrine\ORM\UnitOfWork->getEntityIdentifier(Object(MyEntity)) 
#2 doctrine/orm/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php(1683): Doctrine\ORM\Persisters\BasicEntityPersister->getIndividualValue(Object(MyEntity)) 
#3 doctrine/orm/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php(818): Doctrine\ORM\Persisters\BasicEntityPersister->getValue(Object(MyEntity)) 
#4 doctrine/orm/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php(786): Doctrine\ORM\Persisters\BasicEntityPersister->expandCriteriaParameters(Object(Doctrine\Common\Collections\Criteria)) 
#5 doctrine/orm/lib/Doctrine/ORM/PersistentCollection.php(835): Doctrine\ORM\Persisters\BasicEntityPersister->loadCriteria(Object(Doctrine\Common\Collections\Criteria)) 
#6 (...): Doctrine\ORM\PersistentCollection->matching(Object(Doctrine\Common\Collections\Criteria)) 
#7 (...)

As a workaround I had to control this case explicitly:

if ($myEntity->getId() === null) return null;
$criteria = Criteria::create()->where(Criteria::expr()->eq('field', $myEntity));
return $this->collection->matching($criteria)->first();


 Comments   
Comment by Alexander [ 09/Feb/13 ]

Can you provide us with the mapping of your entities? The code shouldn't get to the point where it asks for the identifier of the object while the object isn't persisted yet.

Comment by Francesc Rosàs [ 10/Feb/13 ]

I'm not sure mapping can help to solve this and is quite a work for me to get it without the client details. Anyway I'll try to reproduce it in a custom scenario if you require it.

I've been doing some debugging and I got this:

  • It still fails with last 2.3.*@stable
  • Entity is persisted before matching(). At UnitOfWork::persistNew(), $this->entityStates[$oid] is set to self::STATE_MANAGED but $this->entityIdentifiers is untouched ($idGen->isPostInsertGenerator() is true)
  • When BasicEntityProvider::getIndividualValue() is called, $value state is STATE_MANAGED but $uow->getEntityIdentifier() fails because $uow->entityIdentifiers[$oid] was never set.

Hope it helps.

Comment by Alexander [ 10/Feb/13 ]

If you can create a testcase and send a PR with it that would be very helpful. You can create it and put in in the appropriate class here:
https://github.com/doctrine/doctrine2/tree/master/tests/Doctrine/Tests/ORM/Functional/Ticket

Comment by Francesc Rosàs [ 16/Feb/13 ]

Here you have: https://github.com/doctrine/doctrine2/pull/582

Comment by Benjamin Eberlei [ 01/May/13 ]

Fixed in 2.4





[DDC-1628] onUpdate parameter on @JoinColumn not supported Created: 31/Jan/12  Updated: 01/May/13  Resolved: 21/Mar/13

Status: Closed
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: 2.2
Fix Version/s: None

Type: Task Priority: Major
Reporter: Chris Richard Assignee: Marco Pivetta
Resolution: Invalid Votes: 3
Labels: None


 Description   

It looks like this is in the older documentation (2.0) but not mentioned in the latest.

I need to use ON UPDATE CASCADE in a few cases. Seems odd to support onDelete and not onUpdate. Am I missing something?



 Comments   
Comment by Benjamin Eberlei [ 31/Jan/12 ]

We removed onUpdate because we couldnt come up with a use-case. CAn you share yours?

Comment by Chris Richard [ 08/Mar/12 ]

I assume it's just the mysql driver but all the constraints get created such that you cannot change the primary keys (even if it's not an auto-gen PK). ON UPDATE CASCADE would probably be a better default.

Comment by Kaspars Sproģis [ 28/Aug/12 ]

I really hope onUpdate annotation attribute will be restored.
I used it in PostgreSQL very often. In some entities in some projects Primary Key ID can be very important its sequence, and if you want to change it, then "ON UPDATE CASCADE" changed it for all the references too. It was must have feature. Now few of my applications are broken with latest doctrine orm.
Please consider restoring it back.
Thank you

Comment by Václav Novotný [ 11/Oct/12 ]

+1 - onUpdate attribute is very useful for PostgreSQL databases, it controls operations with foreign keys.

Comment by Kenneth Kataiwa [ 10/Nov/12 ]

What do you mean, you couldn't come up with a use-case? If one is migrating data from one table to another and requires that all foreign key references be changed to map the ones in the new table created, before deleting the last table. And there are may more case. Maybe I am missing some thing here, if it's a use-case for the MySQL and PostgreSQL guys, why would you not support it.

Comment by Marco Pivetta [ 10/Nov/12 ]

Kenneth Kataiwa updating identifiers is something you don't do, and I sincerely also don't have a use case for this, not in the context of an ORM at least. Also, handling changes in your identifiers in the UnitOfWork is a real problem that adds a lot overhead.

Comment by Václav Novotný [ 12/Nov/12 ]

+1 - onUpdate attribute is very useful for PostgreSQL databases, it controls operations with foreign keys.

I'm taking my words back. It is not a good idea to define onUpdate on foreign keys. Yes, PostgreSQL supports it but it doesn't mean that we should use it in ORM.
Thanks for your time.

Comment by Marco Pivetta [ 21/Mar/13 ]

This issue is invalid, since data migration is not a task for the ORM anyway.

Comment by Gary Golden [ 01/May/13 ]

I have a third party table which holds users:

CREATE TABLE `user`
(
`user_id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
`email` VARCHAR(255) NOT NULL UNIQUE,
) ENGINE=InnoDB CHARSET="utf8";

In my table I want to use natural foreign key, so I reference `email`.

CREATE TABLE `transaction` (
`id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
`user_email` VARCHAR(255) NOT NULL,
FOREIGN KEY (`user_email`) REFERENCES `user`(`email`)
);

I would like to RDBMS handle email updates on the foreign records.

That is a real-life use case of the onDelete, which you decided to remove.
Please, get it back if possible.





[DDC-1776] Abstract class marked as @Entity in a single table inheritance is wrongly hydrated Created: 14/Apr/12  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Benjamin Morel Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None
Environment:

Irrelevant



 Description   

I have the following entity hierarchy:

/**
 * @Entity
 * @InheritanceType("SINGLE_TABLE")
 * @DiscriminatorColumn(name="type", type="string")
 * @DiscriminatorMap({
     "prospectEdited" = "Application\Domain\Model\Event\ProspectEditedEvent"
   })
 */
abstract class Event {
	// ...
}

/**
 * @Entity
 */
abstract class ProspectEvent extends Event {
    /**
     * @ManyToOne(targetEntity="Application\Domain\Model\Prospect")
     */
    protected $prospect;
}

/**
 * @Entity
 */
class ProspectEditedEvent extends ProspectEvent {
	// ...
}

Although ProspectEvent is an abstract class, I need to mark it as @Entity, so that I can query for any type of ProspectEvent:

SELECT e FROM ProspectEvent e WHERE e.prospect = ?

So far, so good.
The problem happens when I query the root class:

SELECT e FROM Event e

The query works fine, but the returned ProspectEvent entities have a NULL $prospect property.
I noticed that in that case, the DocBlock for $prospect is totally ignored (a wrong @JoinColumn name for example, doesn't throw an exception).

The workaround to make it work, is to add a "fake" entry to the discriminator map for the abstract class:

@DiscriminatorMap({
  "prospectEvent"  = "Application\Domain\Model\Event\ProspectEvent"
  "prospectEdited" = "Application\Domain\Model\Event\ProspectEditedEvent"
})

Even though there is no such "prospectEvent" discriminator entry possible, as the class is abstract.
Final point, if I remove the @Entity DocBlock on ProspectEvent, $prospect is hydrated correctly, but then it is not possible to issue a DQL query on ProspectEvent anymore.



 Comments   
Comment by Benjamin Morel [ 29/Nov/12 ]

Any feedback?

Comment by Marco Pivetta [ 23/Jan/13 ]

Benjamin Morel I'd say this has to be fixed in validation. What if we enforce the fake discriminator map? The "workaround" you suggested is actually what you should write with correct mappings.

Comment by Marco Pivetta [ 09/Feb/13 ]

Yes, this has to be reported in validation somehow. The "workaround" is not actually a workaround, but what is expected to be written by the developer.

Comment by Benjamin Morel [ 10/Feb/13 ]

Ok, I found this weird because it's impossible to store a ProspectEvent in the database (as it's abstract), so adding a discriminator entry for it looks weird to me.
I would then suggest one of these two approaches:

  • Either remove the requirement to have a discriminator entry for the parent class if it's abstract (this would be my preference).
  • Or, document this behavior, and throw a proper exception if we try to persist / query such a hierarchy of classes.

But leaving the error unreported, and instantiating incomplete objects, is a real danger!

Comment by Benjamin Eberlei [ 01/May/13 ]

We fixed errors of this kind a while ago





[DDC-2078] [GH-479] [WIP][Mapping] Ported some of the yaml driver to use Symfony config Created: 14/Oct/12  Updated: 01/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of kimhemsoe:

Url: https://github.com/doctrine/doctrine2/pull/479

Message:

Looking for some input. How much validation and normailization should i push to the configuration ? Should i use default values so we can remove alot of lines from the driver ?

Is the way im allowing to extend the configuration good enough for Gedmo and others (untested)?






[DDC-2135] Setting column defaults using options in the annotations causes redundant alter statements Created: 09/Nov/12  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2.2
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Major
Reporter: Cory Comer Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: Cli, schematool


 Description   

When using the Column annotation on an entity and passing the options parameter to set a default value for a column, the doctrine cli will generate the alter statement every time the schema-tool is run.

This doesn't break the functionality of updating the schema using the cli but when you have multiple entities using default values in this manner it becomes cumbersome to investigate issues during updates that fail and you need to dump the generated sql to examine.

Use case: We have a number of entities that include 'boolean' flags. The data for these entities is inserted into the database through an integration process handled by another application. For all of the flags we want to set a default value of 0 to avoid having to modify the integration scripts when a new flag is added to an entity and the data is not available yet.

Example entity:

/**
 * @ORM\Entity
 * @ORM\Table(name="example")
 */
class Example
{
    
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     */
    protected $id;
    
    /** @ORM\Column(type="integer", options={"default" = 0}) */
    protected $disabled;
    
}
$ php bin/doctrine orm:schema-tool:update --dump-sql
ALTER TABLE example CHANGE disabled disabled TINYINT(1) DEFAULT '0' NOT NULL;

This alter statement is generated on every run of the schema-tool even though the schema has already been altered.



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

This is fixed for 2.3.4





[DDC-2218] Unable to set custom PDO instance Created: 31/Dec/12  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.3.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Michał Dobaczewski Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

Hi,

It's impossible to set custom instance of PDO using "pdo" parameter in connection params. Its cause errors like this:

Argument 1 passed to Doctrine\DBAL\Cache\ResultCacheStatement::__construct() must be an instance of Doctrine\DBAL\Driver\Statement, instance of PDOStatement given

Change "Statement $stmt" to just "$stmt" in Doctrine\DBAL\Cache\ResultCacheStatement constructor parameter list sloved problem.

Kind regards,
Michał Dobaczewski



 Comments   
Comment by Marco Pivetta [ 31/Dec/12 ]

Shouldn't you build the driver with your PDO instance?

Comment by Michał Dobaczewski [ 01/Jan/13 ]

Maybe buld custom driver will be better solution but as long this option is in documentation it should work or it should be deleted from documentation.

Comment by Marco Pivetta [ 01/Jan/13 ]

Could you expose your current config?

Comment by Michał Dobaczewski [ 01/Jan/13 ]

I have simple configuration without anything unusual based on code from this page:

 
[...]

$pdoInstance = new PDO('mysql:host=localhost;dbname=somedb', 'root', 'mypassword');

[...]

$connection['driver'] = 'pdo_mysql';
$connection['pdo']    = $pdoInstance; 

[...]

$config = Setup::createConfiguration();

[ Setup annotation driver, cache setup etc. ]

$entityManager = EntityManager::create($connection, $config,  $evm);

And now every Doctrine action which use database cause errors. If write this configuration:

$connection['driver']   = 'pdo_mysql';
$connection['user']     = 'root';
$connection['password'] = 'mypassword';

everything works.

Comment by Marco Pivetta [ 01/Jan/13 ]

Weird... Just went through the code and everything looks fine (See `Doctrine\DBAL\DriverManager#getConnection()`)

Can you check the spl_object_hash of your PDO instance and the one in the DBAL driver? What's your `Connection#getDriver()`?

Comment by Michał Dobaczewski [ 02/Jan/13 ]

I checked the code again and I discovered, that happens If you use Doctrine\ORM\Query\Exec\SingleSelectExecutor with cache but is still a bug. Sorry to confuse you.

Comment by Marco Pivetta [ 02/Jan/13 ]

Michał Dobaczewski can you provide the code to reproduce this then?

Comment by Michał Dobaczewski [ 02/Jan/13 ]
<?php
use Doctrine\ORM\Tools\Setup;
use Doctrine\ORM\EntityManager;

require __DIR__ . '/Doctrine/ORM/Tools/Setup.php';
require __DIR__ . '/Entities/Foo.php';

Doctrine\ORM\Tools\Setup::registerAutoloadPEAR();

$paths = array("Entities");
$isDevMode = false;

$pdoInstance = new PDO('mysql:host=localhost;dbname=mydb', 'root', 'mypass');

// the connection configuration
$dbParams = array(
    'driver'   => 'pdo_mysql',
    'pdo'      => $pdoInstance
);

$config = Setup::createConfiguration($isDevMode);
$driverImpl = $config->newDefaultAnnotationDriver('/Entities');
$config->setMetadataDriverImpl($driverImpl);

$em = EntityManager::create($dbParams, $config);

$query = $em->createQuery('SELECT e FROM Foo e');
$query->useResultCache(true);
$query->setResultCacheLifetime(3600);
$query->setResultCacheDriver($em->getConfiguration()->getQueryCacheImpl());

// Below line is important. It force query to use SQLWalker which use ResultCacheStatement.
$query->setHint($query::HINT_CUSTOM_TREE_WALKERS, array('\Doctrine\ORM\Tools\Pagination\CountWalker'));

$query->getResult();

Foo is whatever correct entity.

Comment by Benjamin Eberlei [ 01/May/13 ]

You need to set the statement to get it working:

$pdo->setAttribute(PDO::ATTR_STATEMENT_CLASS, array('Doctrine\DBAL\Driver\PDOStatement', array()));




[DDC-2307] Fields not wrapped in back ticks when removing entity. Created: 20/Feb/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Alex Mamut Assignee: Benjamin Eberlei
Resolution: Cannot Reproduce Votes: 0
Labels: None


 Description   

Field definition:

/** @Id @Column(type="string", name="`key`") */
    private $_key;

When removing entity mysql.log shows this:

36 Query     START TRANSACTION
                   36 Query     DELETE FROM `settings` WHERE section = 'Test123' AND key = 'test12312'
                   36 Query     rollback

It seems that on a remove statement the field names aren't being wrapped in back ticks.



 Comments   
Comment by Benjamin Eberlei [ 14/Mar/13 ]

Which version are you using? This has been fixed at some point

Comment by Benjamin Eberlei [ 01/May/13 ]

Closing because of no feedback





[DDC-2360] [GH-622] Import EntityManager from proper namespace Created: 21/Mar/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of hrubi:

Url: https://github.com/doctrine/doctrine2/pull/622

Message:



 Comments   
Comment by Benjamin Eberlei [ 21/Mar/13 ]

A related Github Pull-Request [GH-622] was closed
https://github.com/doctrine/doctrine2/pull/622





[DDC-2362] [GH-624] Fix getSQLTableAlias for postgre camelized table name Created: 22/Mar/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of cedriclombardot:

Url: https://github.com/doctrine/doctrine2/pull/624

Message:

In postgreSQL with old databases we can have camelized model names to query on we need to add quote around the table name like :

```

  • @ORM\Table(name="""someThing""")
    ```

But when query is built the alias taken will be `"` this fix will find the good alias to use enabling to query camelized tables



 Comments   
Comment by Benjamin Eberlei [ 22/Mar/13 ]

A related Github Pull-Request [GH-624] was closed
https://github.com/doctrine/doctrine2/pull/624

Comment by Benjamin Eberlei [ 01/May/13 ]

PR was fixed in favor of Doctrine ORM GH-615





[DDC-2238] doctrine:schema:update partially broken Created: 11/Jan/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Tom Vogt Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: postgresql, schematool
Environment:

OS X 10.7.5
PHP 5.4.4
Postgres SQL 9.1.6

also confirmed on:
Linux (Debian testing, Kernel 2.6.32)
PHP 5.4.4
PostgreSQL 9.1.9
Doctrine 2.3.2


Attachments: Text File schemadiff.txt    
Issue Links:
Duplicate
duplicates DBAL-504 DBAL Enum fields migration issue / Po... Awaiting Feedback

 Description   

the app/console doctrine:schema:update command generates a seemingly random number of statements like these:

ALTER TABLE geodata ALTER humidity SET ;
ALTER TABLE geodata ALTER lake SET ;
ALTER TABLE message ALTER translate SET ;

which are obvious invalid SQL commands. The mappings are fine, validate and the application works just fine. Here's an example from the mapping files including two of the above statements:

<field name="coast" type="boolean"/>
<field name="lake" type="boolean"/>
<field name="river" type="boolean"/>
<field name="humidity" type="float"/>
<field name="biome" type="string"/>

I am using doctrine2-spatial as an extension for GIS information. This problem shows up both in entities using spatial data and entities not using spatial data.

I'll gladly help debug this, as right now I can't update my dev database with --force, I need to use --dump-sql and filter out the invalid lines.



 Comments   
Comment by Benjamin Eberlei [ 12/Jan/13 ]

Can you dump the SchemaDiff/ColumnDiff instances that are returned from lib/Doctrine/DBAL/Schema/Comparator.php?

Comment by Tom Vogt [ 12/Jan/13 ]

requested dump of SchemaDiff

Comment by Tom Vogt [ 12/Jan/13 ]

added in the file schemadiff.txt - I added this in Schematool.php - getUpdateSchemaSql():

$comparator = new Comparator();
$schemaDiff = $comparator->compare($fromSchema, $toSchema);
\Doctrine\Common\Util\Debug::dump($schemaDiff, 6);

if you need other output, just tell me what entity to dump and where. I'll be happy to help.

The file also contains the buggy update statements it creates towards the end. There's a few non-crucial bugs included, where it alters the geospatial columns to themselves (i.e. river.course already is a geometry/linestring). I don't worry about those because they don't break anything.

Comment by Tom Vogt [ 15/Apr/13 ]

Is there any update on this? I'm still having this issue, with many different entities, always the same problem, for example:

ALTER TABLE event ALTER priority SET ;

Which is an integer field on an entity that doesn't have any GIS elements, so I'm not even sure if it's caused by that anymore.

Comment by Benjamin Eberlei [ 01/May/13 ]

Tom Vogt I added a fix for PostgreSQL today, can you verify again if this works? Its included in the 2.3 branch.

Comment by Benjamin Eberlei [ 01/May/13 ]

Duplicate of http://www.doctrine-project.org/jira/browse/DBAL-504





[DDC-2406] Merging of new detached entities with PrePersist lifecycle callback breaks Created: 19/Apr/13  Updated: 01/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Oleg Namaka Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: merge,, prePersist


 Description   

Merging of new detached entities with PrePersist lifecycle callback breaks:

Code snippet:

    class A
    {
       /**
        *  @ORM\ManyToOne(targetEntity= ...
        *  @ORM\JoinColumn(name=" ...
        */
        protected $b;
        
        public function getB()
        {
            return $this->b;
        }
        
        public function setB($b)
        {
            $this->b = $b;
        }
        
        /**
         *
         * @ORM\PrePersist
         *
         * @return void
         */
        public function onPrePersist()
        {
           if ($this->getB() === null) {
                throw new \Exception('B instance must be defined);
           }
           ....
        }
    }
    
    class B 
    {
    }
    
    $a = new A();
    $b = $em->find('B', 1);
    $a->setB($b);
    $em->persist($a); // works fine as B instance is set
    $em->detach($a);
    
    $a = $em->merge($a) // breaks in onPrePersist

The reason it happens is that the merge operation is trying to persist a new entity created by uow::newInstance($class) without populating its properties first:

 // If there is no ID, it is actually NEW.
    ....
    if ( ! $id) {
        $managedCopy = $this->newInstance($class);

        $this->persistNew($class, $managedCopy);
    } else {
	....

This should happen first for the $managedCopy:

    // Merge state of $entity into existing (managed) entity
    foreach ($class->reflClass->getProperties() as $prop) {
        ....


 Comments   
Comment by Fabio B. Silva [ 28/Apr/13 ]

Benjamin Eberlei, Is this an expected behavior ?

I mean.. This issue is about dispatch the event before copy the original values into the managed instance.
But overall, should $em->detach() trigger @PrePersist events ?

Comment by Benjamin Eberlei [ 01/May/13 ]

Fabio B. Silva he talks about $em->merge() on a detached entity calling pre persist. This should only happen on a NEW entity, not on a DETACHED one.

Comment by Oleg Namaka [ 01/May/13 ]

I tend to disagree with the statement above about pre persist that should not happen on a detached entity being merged back in. If this event handler contains a business logic that this entity needs to be checked against and the detached entity was modified before the merge operation in a way that invalidates it in the prePersist than I will end up with the invalid entity in the identity map. If the merge operation calls persist it must run the prePersist event handler as well for consistency.

If there is a logic that prevents persisting invalid entities why should it bypassed in the merge operation?





[DDC-2391] [GH-643] DDC-2390: Remove Query dependency in SqlWalker and Parser Created: 04/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of beberlei:

Url: https://github.com/doctrine/doctrine2/pull/643

Message:

To prevent future problems with illegal Query parameter access and also to decouple the namespaces by removing bidirectional dependency.



 Comments   
Comment by Doctrine Bot [ 01/May/13 ]

A related Github Pull-Request [GH-643] was closed:
https://github.com/doctrine/doctrine2/pull/643





[DDC-2414] Unable to create One-To-Many relation with composite keys Created: 25/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, Tools
Affects Version/s: Git Master, 2.3.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Bruno CHALOPIN Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: composite
Environment:

Ubuntu 12.04, PHP 5.4.9



 Description   

Given these entities :

/**
 * Class Domain
 *
 * @Entity
 * @Table(name="profils_domains")
 */
class Domain
{
    /**
     * @var string
     *
     * @Id
     * @Column(type="string", length=22, nullable=false)
     */
    protected $name = '';
}
/**
 * Class User
 *
 * @Entity
 * @Table(name="profils_users")
 */
class User
{
    /**
     * @var string
     *
     * @Id
     * @Column(type="string", length=22, nullable=false)
     */
    protected $name = '';

    /**
     * @var Domain
     *
     * @Id
     * @ManyToOne(targetEntity="Domain", fetch="LAZY")
     * @JoinColumn(name="domain", referencedColumnName="name", onDelete="CASCADE")
     */
    protected $domain;
    
    /**
     * @var Group[]|ArrayCollection
     *
     * @ManyToMany(targetEntity="Group", mappedBy="users")
     */
    protected $groups;
}
/**
 * Class Group
 *
 * @Entity
 * @Table(name="profils_groups")
 */
class Group
{
    /**
     * @var string
     *
     * @Id
     * @Column(type="string", length=22, nullable=false)
     */
    protected $name = '';

    /**
     * @var Domain
     *
     * @Id
     * @ManyToOne(targetEntity="Domain", fetch="LAZY")
     * @JoinColumn(name="domain", referencedColumnName="name", onDelete="CASCADE")
     */
    protected $domain;
    
    /**
     * @var User[]|ArrayCollection
     *
     * @ManyToMany(targetEntity="User", indexBy="name", fetch="EXTRA_LAZY")
     * @JoinTable(name="profils_groups_users",
     *      joinColumns={
     * @JoinColumn(name="group_name", referencedColumnName="name", onDelete="CASCADE"),
     * @JoinColumn(name="domain", referencedColumnName="domain", onDelete="CASCADE")
     *          },
     *      inverseJoinColumns={
     * @JoinColumn(name="user_name", referencedColumnName="name", onDelete="CASCADE"),
     * @JoinColumn(name="domain", referencedColumnName="domain", onDelete="CASCADE")
     *          }
     *      )
     */
    protected $users;
}

I want to link users and groups but only from the same domain.
I also want a user to be in one group only.
The only way with composite keys is to make One-To-Many, Unidirectional with Join Table but I can't put unique=true in the @JoinColumn of my inverseJoinColumns because it will generate a unique index for each field and not one composite. I also can't use @UniqueConstraint as it is not supported in @JoinTable.



 Comments   
Comment by Fabio B. Silva [ 28/Apr/13 ]

Hi Bruno,

Could you please explain it a little deeper ?
you describe an one-to-many relation but your mapping has a many-to-many Group#users.

Also, you shoud describe operations you are executing and which errors you got.

Cheers

Comment by Bruno CHALOPIN [ 29/Apr/13 ]

Hi fabio,

The relation i was trying to make is http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/association-mapping.html#one-to-many-unidirectional-with-join-table

However, it implies to use a unique contraint and as explain above when trying to create the schema via doctrine, as i use composite keys, it will generate 2 unique contraints (one for each field) and not one composite unique constraint.

Nevertheless, it seems like using composite keys is a lot buggy in doctrine (see http://www.doctrine-project.org/jira/browse/DDC-2413)

Comment by Benjamin Eberlei [ 01/May/13 ]

We discussed this in DDC-2413, this is not supported by Doctrine.





[DDC-2421] Many-To-Many relation creation failed when using non PK entity field Created: 29/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, Tools
Affects Version/s: Git Master, 2.3.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Bruno CHALOPIN Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: schematool
Environment:

Ubuntu linux 12.04, php 5.4.9



 Description   

Given these entities :

/**
 * Class Domain
 *
 * @ORM\Entity
 * @ORM\Table(name="profils_domains")
 */
class Domain
{
    /**
     * @var string
     *
     * @ORM\Id
     * @ORM\Column(type="string", length=22, nullable=false)
     */
    protected $name = '';
}
/**
 * Class Web
 *
 * @ORM\Entity
 * @ORM\Table(name="profils_webs",
 *          uniqueConstraints={@ORM\UniqueConstraint(name="web_unique",columns={"name", "domain"})}
 * )
 */
class Web
{
    /**
     * @var integer
     *
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer", nullable=false)
     */
    protected $id;

    /**
     * @var string
     *
     * @ORM\Column(type="string", length=22, nullable=false)
     */
    protected $name = '';

    /**
     * @var Domain
     *
     * @ORM\ManyToOne(targetEntity="Domain", fetch="LAZY")
     * @ORM\JoinColumn(name="domain", referencedColumnName="name", nullable=false, onDelete="CASCADE")
     */
    protected $domain;
}
/**
 * Class WebsGroup
 *
 * @ORM\Entity
 * @ORM\Table(name="profils_websgroups",
 *          uniqueConstraints={@ORM\UniqueConstraint(name="websgroup_unique",columns={"name", "domain"})}
 * )
 */
class WebsGroup
{
    /**
     * @var integer
     *
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer", nullable=false)
     */
    protected $id;

    /**
     * @var string
     *
     * @ORM\Column(type="string", length=22, nullable=false)
     */
    protected $name = '';

    /**
     * @var Domain
     *
     * @ORM\ManyToOne(targetEntity="Domain", fetch="LAZY")
     * @ORM\JoinColumn(name="domain", referencedColumnName="name", nullable=false, onDelete="CASCADE")
     */
    protected $domain;

    /**
     * @var ArrayCollection
     *
     * @ORM\ManyToMany(targetEntity="Web", indexBy="id", fetch="EXTRA_LAZY")
     * @ORM\JoinTable(name="profils_websgroups_webs",
     *      joinColumns={
     * @ORM\JoinColumn(name="websgroup_id", referencedColumnName="id", onDelete="CASCADE"),
     * @ORM\JoinColumn(name="domain", referencedColumnName="domain", onDelete="CASCADE")
     *          },
     *      inverseJoinColumns={
     * @ORM\JoinColumn(name="web_id", referencedColumnName="id", onDelete="CASCADE"),
     * @ORM\JoinColumn(name="domain", referencedColumnName="domain", onDelete="CASCADE")
     *          }
     *      )
     */
    protected $webs;
}

I've got a domain, some web sites per domain and websgroups which group web sites. I want to be sure in my database that a web group from a domain D can contain only web sites from the very same domain but when calling the console tool for creating my schema it raise :

[Doctrine\ORM\ORMException]                                                                                                                                      
  Column name `domain` referenced for relation from Entity\WebsGroup towards Entity\Web does not exist. 

It's because domain is already an association to an entity which and is not part of the primary key.

I've quick fixed getDefiningClass from Doctrine\ORM\Tools\SchemaTool to make it work but i really don't know if it's the proper way :

    private function getDefiningClass($class, $referencedColumnName)
    {
        $referencedFieldName = $class->getFieldName($referencedColumnName);

        if ($class->hasField($referencedFieldName)) {
            return array($class, $referencedFieldName);
        } else if (in_array($referencedColumnName, $class->getIdentifierColumnNames())) {
            // it seems to be an entity as foreign key
            foreach ($class->getIdentifierFieldNames() as $fieldName) {
                if ($class->hasAssociation($fieldName) && $class->getSingleAssociationJoinColumnName($fieldName) == $referencedColumnName) {
                    return $this->getDefiningClass(
                        $this->em->getClassMetadata($class->associationMappings[$fieldName]['targetEntity']),
                        $class->getSingleAssociationReferencedJoinColumnName($fieldName)
                    );
                }
            }
        } else if (in_array($referencedColumnName, $class->getAssociationNames())) {
            return $this->getDefiningClass(
                $this->em->getClassMetadata($class->associationMappings[$referencedColumnName]['targetEntity']),
                $class->getSingleAssociationReferencedJoinColumnName($referencedColumnName)
            );
        }

        return null;
    }


 Comments   
Comment by Fabio B. Silva [ 29/Apr/13 ]

Bruno CHALOPIN Except for some CS this fix seems good.

If you have time you can send as pull request

Comment by Bruno CHALOPIN [ 30/Apr/13 ]

I've start making a PR and a test case but it is linked to http://www.doctrine-project.org/jira/browse/DDC-2413
I'm looking in making a proper fix to DDC-2413 first.

Comment by Benjamin Eberlei [ 01/May/13 ]

You cannot use a reference column that is not a primary key. Doctrine does not support this.





[DDC-2419] [GH-655] [DDC-2409] Fix merge association UnitOfWork::STATE_NEW Created: 28/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4, 2.3.4
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of FabioBatSilva:

Url: https://github.com/doctrine/doctrine2/pull/655

Message:

http://www.doctrine-project.org/jira/browse/DDC-2409



 Comments   
Comment by Doctrine Bot [ 01/May/13 ]

A related Github Pull-Request [GH-655] was closed:
https://github.com/doctrine/doctrine2/pull/655





[DDC-2423] [GH-657] DDC-2413 Created: 01/May/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of JEDIBC:

Url: https://github.com/doctrine/doctrine2/pull/657

Message:

Fix DDC-2413



 Comments   
Comment by Doctrine Bot [ 01/May/13 ]

A related Github Pull-Request [GH-657] was closed:
https://github.com/doctrine/doctrine2/pull/657





[DDC-2143] $em->refresh($entity) doesn't refresh associations cleared with clear() Created: 14/Nov/12  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Critical
Reporter: Alex Assignee: Benjamin Eberlei
Resolution: Cannot Reproduce Votes: 0
Labels: None
Environment:

PHP 5.3 + APC, CentOS


Attachments: File DDC2143Test.php    
Issue Links:
Duplicate
is duplicated by DDC-1987 Cascading "refresh" does not work on ... Resolved

 Description   

  // $entity->items is m2m association

  /////////////////////
  // 1. Bug

  echo $entity->items->count(); // 2

  $entity->items->clear();

  echo $entity->items->count(); // 0

  $em->refresh($entity);

  echo $entity->items->count(); // 0 <-- ???

  //////////////////
  // 2. Workaround

  echo $entity->items->count(); // 2

  // remove items one by one

  $items = $entity->items->toArray();
  foreach ( $items as $item )
  {
    $entity->items->removeElement($item);
  }

  echo $entity->items->count(); // 0

  $em->refresh($entity);

  echo $entity->items->count(); // 2, as expected



 Comments   
Comment by Marco Pivetta [ 23/Jan/13 ]

This is because `clear` on an un-initialized collection doesn't initialize it. Can you confirm this by adding a call to

$this->initialize()

in the `clear` method of `Doctrine\ORM\PersistentCollection`?

Comment by Marco Pivetta [ 23/Jan/13 ]

Related to DDC-1987

Comment by Marco Pivetta [ 21/Feb/13 ]

Alex ping?

Comment by Benjamin Eberlei [ 31/Mar/13 ]

I cannot reproduce this issue, see the testscript attached (put into tests/Doctrine/Tests/ORM/Functional/Ticket/). Can you try to make this code fail?

Comment by Benjamin Eberlei [ 01/May/13 ]

Closed, no feedback.





[DDC-2235] Single table inheritance discriminator in WHERE when using arbitrary join syntax Created: 11/Jan/13  Updated: 29/Apr/13  Resolved: 14/Apr/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Jordi Forns Assignee: Alexander
Resolution: Duplicate Votes: 3
Labels: None

Issue Links:
Duplicate
duplicates DDC-1940 Doctrine DQL: erroneous sql generatio... Open

 Description   

The condition on the discriminator column is placed in the WHERE clause when using arbitrary join syntax, which renders LEFT JOINs useless.

Given these classes:
A - no inheritance
B1 - abstract, root of a hierarchy, discriminator column is named 'type'
I setup a query builder like this:

$qb->select('a.id AS idA, b.id AS idB')
    ->from('\Entity\A', 'a')
    ->leftJoin('\Entity\B1', 'b', \Doctrine\ORM\Query\Expr\Join::WITH, 'a.something=b.something');
And the SQL Doctrine generates is something like this:
SELECT a.id, b.id FROM a LEFT JOIN b ON (a.something=b.something) WHERE b.type IN ('1', '2', '3')

The problems is that the WHERE condition makes the left join useless.

The condition on the discriminator column should be placed in the JOIN clause to avoid the problem.



 Comments   
Comment by Ondrej Hlavaty [ 10/Feb/13 ]

Can this be somehow worked around? If not, it is really serious problem...

Comment by Jordi Forns [ 18/Feb/13 ]

I couldn't find any workaround.
Trying to force the 'type' condition in the join clause resulted useless as Doctrine would add the 'where' condition regardless.

Comment by Michel Salib [ 22/Mar/13 ]

Easier way to workaround right now, is to declare a OneToMany from class A to class B on a protected field (no need of getter or setter). That way you can do classic join via relationship transversing and then the condition will be placed in the ON part of the query.

Comment by Yuta Konishi [ 01/Apr/13 ]

I could access with below codes. You should use RAW SQL it is easy solution I guess. good luck.

$qb = $em->createQueryBuilder();

$qb->select('a, b')
->from('YourEntity1', 'a')
->leftJoin('YourEntity2', 'b', \Doctrine\ORM\Query\Expr\Join::WITH, 'a.id = b.relationId');

$raw_sql = $qb->where( 
	$qb->expr()->in('a.relationId', $ids)
)
->orderBy('a.updatedAt', 'DESC')
->setMaxResults(10)
->getQuery()->getSQL();

$conn = $em->getConnection();
$stmt = $conn->query($raw_sql);

/* $stmt->fetchAll(); // access as Array */
Comment by Benjamin Eberlei [ 04/Apr/13 ]

Assigned to Alexander

Comment by Benjamin Eberlei [ 14/Apr/13 ]

Duplicate of DDC-1940

Comment by Jordi Forns [ 22/Apr/13 ]

Benjamin: this bug doesn't seem to be a dupe of DDC-1940. Actually that issue doesn't seem to be a bug at all.

As a reminder, the problem in this issue is that when performing arbitrary left joins on entities that are part of a class hierarchy, the discriminator condition is placed in the where clause instead of the join clause. This means that rows that could not be joined will have null values in the discriminator column and thus will not be returned because of the where condition (which will contain something like " where x.discriminator in (1,2,3) ").

Comment by Tom Arnfeld [ 27/Apr/13 ]

Has this issue been resolved elsewhere? From reading over DDC-1940 it doesn't seem to be a duplicate at all. I'm experiencing the same problem as Jordi and can't seem to find a solution. Is there any particular reason the `IN ()` predicate is not a part of the join, but instead placed in the main `WHERE` clause?

Comment by Tom Arnfeld [ 28/Apr/13 ]

I've been looking into the root cause of this bug (or feature..) to try and understand why it's happening, and after trying various possible fixes (a little hard without full understanding of the Doctrine/Query internals) I've ended up with a fix that seems to work well for my use case, at least. I've not run any of the unit tests (I plan to, and may adjust my fix based on that) but the top revision is my change... https://gist.github.com/tarnfeld/a6bb50ec707c7af1c5dc/revisions

Would love some feedback.

Pull request here: https://github.com/doctrine/doctrine2/pull/656

Comment by Jordi Forns [ 29/Apr/13 ]

Tom's fix moves the condition of the discriminator column to the LEFT JOIN, which is exactly what was needed.

Alexander: could you please give it a look?





[DDC-2420] [GH-656] [DDC-2235] Fix for using a LEFT JOIN onto an entity with single table inheritance Created: 28/Apr/13  Updated: 28/Apr/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of tarnfeld:

Url: https://github.com/doctrine/doctrine2/pull/656

Message:

Possible fix for the bug DDC-2235. I'd love to hear some opinions on whether this is the right way to go about this issue. I'm not particularly familiar with the internals of doctrine so there may be a better solution.

------

The issue is when using DQL to perform a left join on an entity using single
table inheritance, doctrine tries to insert an `IN()` predicate into the `WHERE`
clause for all of the discriminator values. That makes sense and is valid, so
it would be wrong to remove that behaviour.

However when using a left join having an `IN()` in the main where clause makes
the `LEFT JOIN` pretty much useless, as it implicitly creates a `WHERE NOT NULL`
clause. This commit attempts to fix that by including an `OR IS NULL` in the
query if the join is a `LEFT JOIN`.

I've added some regression tests to ensure this bug never creeps back in. They fail on master (highlighting the bug) and pass after these commits have been applied. I've also included a couple of other queries as tests to be sure only this one case has been affected.






[DDC-2415] CustomIdGenerator not inherited from MappedSuperclass Created: 25/Apr/13  Updated: 27/Apr/13  Resolved: 27/Apr/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Sebastian Calvo Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: orm


 Description   

I had a problem with a CUSTOM id generation mapping definition.
I have an abstract class and @MappedSuperclass which defines the id column as:

/**

  • @ORM\Id
  • @ORM\Column(name="ID", type="integer")
  • @ORM\GeneratedValue(strategy="CUSTOM")
  • @ORM\CustomIdGenerator(class="Infoil\Extensions\ExtensionsBundle\DoctrineIdGenerator\ZafiroIdGenerator")
  • @var int $id
    */
    The problem is that subclasses doesn't inherits the CustomIdGenerator annotation. I have traced the problem up to ClassMetadataFactory::doLoadMetadata.
    I had to change the second inner if statement as

if ($parent->isMappedSuperclass)

{ $class->setCustomRepositoryClass($parent->customRepositoryClassName); $class->setCustomGeneratorDefinition($parent->customGeneratorDefinition); <<<<< LINE ADDED }

to allow subclasses inherit the customGenerationdefinition.

Aside, the docblock annotation help doesn't includes the CustomIdGenerator tag.



 Comments   
Comment by Fabio B. Silva [ 27/Apr/13 ]

Fixed : https://github.com/doctrine/doctrine2/commit/d513e0f084eb4e67ccb42877b28a27d47a561665





[DDC-2418] [GH-654] Ilike Created: 27/Apr/13  Updated: 27/Apr/13  Resolved: 27/Apr/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of lighthart:

Url: https://github.com/doctrine/doctrine2/pull/654

Message:

Ilike expression added for postgres support



 Comments   
Comment by Doctrine Bot [ 27/Apr/13 ]

A related Github Pull-Request [GH-654] was closed:
https://github.com/doctrine/doctrine2/pull/654





[DDC-2417] [GH-653] [DDC-2415] Fix CustomIdGenerator inheritance Created: 26/Apr/13  Updated: 27/Apr/13  Resolved: 27/Apr/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of FabioBatSilva:

Url: https://github.com/doctrine/doctrine2/pull/653

Message:

http://www.doctrine-project.org/jira/browse/DDC-2415



 Comments   
Comment by Doctrine Bot [ 27/Apr/13 ]

A related Github Pull-Request [GH-653] was closed:
https://github.com/doctrine/doctrine2/pull/653





[DDC-2416] [GH-652] Fixed entities path Created: 26/Apr/13  Updated: 26/Apr/13  Resolved: 26/Apr/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of dannykopping:

Url: https://github.com/doctrine/doctrine2/pull/652

Message:

In the tutorial, the user is told to create a new file in the `/src` folder, and the `/entities` folder is never referenced. Updating the SQLite schema according to the tutorial fails with the 'No Metadata Classes to process.' message. Changing the folder to `/src` fixes this, ostensibly.



 Comments   
Comment by Doctrine Bot [ 26/Apr/13 ]

A related Github Pull-Request [GH-652] was closed:
https://github.com/doctrine/doctrine2/pull/652

Comment by Marco Pivetta [ 26/Apr/13 ]

merged





[DDC-2412] [GH-651] Fixed typo in SQLFilter (use statement ClassMetadata) Created: 23/Apr/13  Updated: 23/Apr/13  Resolved: 23/Apr/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of EuKov:

Url: https://github.com/doctrine/doctrine2/pull/651

Message:



 Comments   
Comment by Doctrine Bot [ 23/Apr/13 ]

A related Github Pull-Request [GH-651] was closed:
https://github.com/doctrine/doctrine2/pull/651

Comment by Marco Pivetta [ 23/Apr/13 ]

merged





[DDC-776] Persisters use a fixed "SELECT" SQL statements Created: 29/Aug/10  Updated: 23/Apr/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.0-BETA3
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Aaron DM Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Windows 7, Apache 2.2, MSSQL Server, PHP 5.3.3



 Description   

I am currently trying to work with BINARY columns with Doctrine 2 and MSSQL. In order to get my Entities working I had to create a custom Mapping Type for Binary columns. All went well in this case and I've got it running.

The problem arises when I am attempting to use Associative mapping (OneToOne/ManyToMany). The problem is, in order to do a select for an SQL column, I had to create a DQL function called "CONVERT" so that I use WHERE statements:

return $this->createQueryBuilder('u')
->where("u.id = CONVERT('binary', :id, 1)")
->setParameter('id', $id)
->getQuery()
->getSingleResult();

As you see, I must do this in order to get a result.

However, when I'm using associative mapping; this is what it does:

return 'SELECT ' . $this->_getSelectColumnListSQL()
. ' FROM ' . $this->_class->getQuotedTableName($this->_platform) . ' '
. $this->_getSQLTableAlias($this->_class->name)
. $joinSql
. ($conditionSql ? ' WHERE ' . $conditionSql : '')
. $orderBySql
. $lockSql;

As you can see, its some what hard coded and I cannot change it without changing the actual code in
Doctrine\ORM\Persisters\BasicEntityPersister.php

So, I would first like to know if there was maybe a way you could allow us to customize the SELECT statement that the persisters use - or maybe (though I'm not sure how this will be done) make them use user-defined repository functions?

Like $myRepo->find($identifier)

Not entirely sure if I explained this properly and I do realize my circumstance is highly odd - but this does seem like a limitation and because of this I cannot use associative mapping.



 Comments   
Comment by locs [ 23/Apr/13 ]

Hi, i try to make my custom type for binary field in MSSQL.
I don't find own, can you please show me your custom type binary?
Thks a lot.





[DDC-2410] [GH-650] Fixed typo in SQLFilter addFilterConstraint first param Created: 23/Apr/13  Updated: 23/Apr/13  Resolved: 23/Apr/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of EuKov:

Url: https://github.com/doctrine/doctrine2/pull/650

Message:

Hi,

Description in subj,
the use statement for ClassMetaData is
use Doctrine\ORM\Mapping\ClassMetaData;

But in the abstract method the param named ClassMetadata ("d" char should be in uppercase)



 Comments   
Comment by Doctrine Bot [ 23/Apr/13 ]

A related Github Pull-Request [GH-650] was closed:
https://github.com/doctrine/doctrine2/pull/650





[DDC-2388] Zend Optimizer Plus/opcache have overlap in config settings, annotations reader doesn't identify these properly Created: 04/Apr/13  Updated: 23/Apr/13  Resolved: 20/Apr/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: 2.3.3
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Ross Cousens Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

Doctrine\Common\Annotations\AnnotationReader.php

A change was recently authored in the AnnotationReader constructor that checked for a properly configured opcode cache (namely saving comments so that Doctrine can parse annotations).

The current open source version of Zend Optimizer+ hosted at GitHub (https://github.com/zend-dev/ZendOptimizerPlus) when loaded registers itself as a module with the name "Zend Optimizer+" but takes configuration directives in the form of "opcache.<parameter>".

The change to the constructor requires that if the module name is Zend Optimizer+, then the configuration directives must be prefixed with "zend_optimizerplus.<parameter>". This is clearly incorrect.

The most recent update now complains of an AnnotationException as a consequence of this change when running Symfony2 (or Doctrine) with the latest opcache because configuration directives aren't detected properly.

I am happy to fix this but could not find a way to report an issue to initiate the process.

I would suggest something like this in the constructor:

if ((extension_loaded('Zend Optimizer+') || extension_loaded('opcache')) && !(ini_get('opcache.save_comments') == 0 XOR ini_get('zend_optimizerplus.save_comments') == 0)) {

What this means is that if either extension is loaded, one of those directives must be true and configured. This is a compromise. The alternative would be to keep the original source and do the following:

if (extension_loaded('Zend Optimizer+') && ini_get('zend_optimizerplus.save_comments') == 0) {
if (ini_get('opcache.save_comments') == 0)

{ throw AnnotationException::optimizerPlusSaveComments(); }

}

if (extension_loaded('opcache') && ini_get('opcache.save_comments') == 0)

{ throw AnnotationException::optimizerPlusSaveComments(); }

I have no idea about the "opcache" module and what it actually equates to or whether it has alternative formats for its configuration directives. I feel like the second suggestion is even smellier than my original suggestion despite probably handling the edge case better.

If you want a pull request, I will send one, just let me know how you want to handle it.

If my PHP is horrible I apologise.



 Comments   
Comment by Marco Pivetta [ 04/Apr/13 ]

Ross Cousens is this already enstabilished? It's not worth changing it until the ZO+ stuff is stable.

Comment by Ross Cousens [ 15/Apr/13 ]

Marco Pivetta Benjamin Eberlei

Seems stable to me.

I guess whether this is a priority or not depends on your subjective weighting of its importance and whether or not you use ZO+. I've ditched APC, and moved 20+ web servers over to Apache+ZO+. I currently deploy my own version of DBAL commons because it is not possible to work around it.

https://github.com/zend-dev/ZendOptimizerPlus

Please see this reference, why would they suddenly change the name of all the configuration directives especially in light of the fact that this is being integrated into PHP 5.5 as the standard generic "opcache" solution? I think this is where the confusion comes from. It might be branded as ZO+ on Github, but that becomes irrelevant when it's part of core.

I've tried contacting Beberlei directly (the author of the change), on Twitter and via e-mail, but no response. Not getting any response is quite annoying as it's been a month since this change was made and whenever I update an existing site or publish a new site I have to deal with this.

I need to invest some time in finding out how I can maintain my own fork of OSS projects that pull changes in from the branched master but allow me to keep 1 or 2 files totally different. The other thing that drives me insane is the fact that the postgresql platform drivers can't implement GUID generators because it requires an extension be enabled on the server (seriously, solve with documentation, it's easy to detect programmatically as well) plus the choosing of a function, when there is obviously only one sane choice.

I am so grateful for the opportunity to develop with OSS, but the bureaucratic decision-by-committee stuff is so frustrating when you're an end-user and can't find anyone who gives half a crap about stuff that is just plain stupid but overlooked due to resources already spread thin or whatever may be the case. I would be happy to develop fixes as well, but when they languish because you can't find a maintainer that is familiar with the issue, interested in finding a fix, and has the time available to act as custodian of a pull request, it is incredibly demoralizing.

Comment by Benjamin Eberlei [ 20/Apr/13 ]

Fixed and released a Collections 1.1.1 version

Comment by Ross Cousens [ 23/Apr/13 ]

Thanks Benjamin, I am grateful for the fix! Happy coding!





[DDC-2229] Undefined method Created: 09/Jan/13  Updated: 22/Apr/13  Resolved: 08/Apr/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Karma Dordrak (Drak) Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None

Attachments: Text File SqlWalker.patch     File SqlWalkerTest.php    

 Description   

There is an undefined method called in Doctrine\ORM\Query\SqlWalker

Fatal error: Call to undefined method Doctrine\ORM\Query\AST\PathExpression::isSimpleArithmeticExpression() in vendor\doctrine\orm\lib\Doctrine\ORM\Query\SqlWalker.php on line 2091



 Comments   
Comment by Fabio B. Silva [ 12/Jan/13 ]

Hi Karma

Could you provide the failing DQL ?

Cheers

Comment by Karma Dordrak (Drak) [ 18/Jan/13 ]

It's generating SQL from a Doctrine Collection in a proxy class. Here is a link to the example: https://github.com/zikula/core/pull/674#discussion_r2696186

The SQL being generated is

`SELECT t0.name AS name1, t0.value AS value2, t0.user_id AS user_id3 FROM users_attributes t0 WHERE t0.user_id = ?`

The ? should be the value 2, but for some reason it's not being added. I've checked the files in the stack-trace below and the right values are entering into the process, just the wrong SQL seems to be generated.

Exception Trace
#0 Exception thrown in C:\xampp\htdocs\core13\src\vendor\doctrine\dbal\lib\Doctrine\DBAL\DBALException.php, line 47.
#1 C:\xampp\htdocs\core13\src\vendor\doctrine\orm\lib\Doctrine\ORM\Persisters\BasicEntityPersister.php(1599): Doctrine\DBAL\Connection->executeQuery('SELECT t0.name ...', Array, Array)
#2 C:\xampp\htdocs\core13\src\vendor\doctrine\orm\lib\Doctrine\ORM\Persisters\BasicEntityPersister.php(1558): Doctrine\ORM\Persisters\BasicEntityPersister->getOneToManyStatement(Array, Object(Users\Entity\User))
#3 C:\xampp\htdocs\core13\src\vendor\doctrine\orm\lib\Doctrine\ORM\UnitOfWork.php(2673): Doctrine\ORM\Persisters\BasicEntityPersister->loadOneToManyCollection(Array, Object(Users\Entity\User), Object(Doctrine\ORM\PersistentCollection))
#4 C:\xampp\htdocs\core13\src\vendor\doctrine\orm\lib\Doctrine\ORM\PersistentCollection.php(224): Doctrine\ORM\UnitOfWork->loadCollection(Object(Doctrine\ORM\PersistentCollection))
#5 C:\xampp\htdocs\core13\src\vendor\doctrine\orm\lib\Doctrine\ORM\PersistentCollection.php(576): Doctrine\ORM\PersistentCollection->initialize()
#6 C:\xampp\htdocs\core13\src\lib\util\UserUtil.php(1152): Doctrine\ORM\PersistentCollection->getIterator()
#7 C:\xampp\htdocs\core13\src\lib\util\UserUtil.php(2007): UserUtil::getVars('admin', false, 'uname', false)

Comment by Fabio B. Silva [ 20/Jan/13 ]

Hi Drak,

Could you try to write a failing test case please ?

Cheers

Comment by Alexander [ 10/Feb/13 ]

ping!

Comment by Daniel Huss [ 14/Feb/13 ]

SqlWalker::walkInExpression() does this:

$sql = $this->walkArithmeticExpression($inExpr->expression)

However, $inExpr->expression could be an instance of PathExpression. The grammar allows this case:

InExpression             ::= SingleValuedPathExpression ["NOT"] "IN" "(" (InParameter {"," InParameter}* | Subselect) ")"

PathExpression and ArithmeticExpression both extend Node, but a PathExpression is not an ArithmeticExpression, and therefore it has no method isSimpleArithmeticExpression.

If you still need a failing test case, I'll write one when I get home from work.

Comment by Fabio B. Silva [ 14/Feb/13 ]

Please Daniel Huss, A test case will be very useful..

Comment by Daniel Huss [ 15/Feb/13 ]

failing test case

Comment by Daniel Huss [ 02/Apr/13 ]

Bug still present in release 2.3.3

Is someone taking care of this? It seems easy enough to fix.

Comment by Marco Pivetta [ 02/Apr/13 ]

Daniel Huss you can open a PR with the attached patch + test. Can you do it or should I take care of it?

Comment by Daniel Huss [ 02/Apr/13 ]

Please take care of it for me this time. I'd rather avoid the git setup until I have a significant contribution to make.

Comment by Benjamin Eberlei [ 08/Apr/13 ]

This is invalid, you need to set the path expression differently, this is pseudo code:

new ArtihmeticExpression(new SimpleArithmeticExpression(arithmeticsTerms => new PathExpression)));
Comment by Daniel Huss [ 22/Apr/13 ]

Could this be bug in the DQL grammar, then? If I'm not mistaken, the resolution of an InExpression cannot involve an ArithmeticPrimary non-terminal. I find the correct solution as shown by Benjamin Eberlei to be quite astonishing, since a path expression like "alias.field" is not something I'd associate with the term "arithmetic".





[DDC-2408] [GH-649] Update coding standards Created: 21/Apr/13  Updated: 21/Apr/13  Resolved: 21/Apr/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of calumbrodie:

Url: https://github.com/doctrine/doctrine2/pull/649

Message:

Removing underscores from property/method names and change use statements to PSR-2



 Comments   
Comment by Doctrine Bot [ 21/Apr/13 ]

A related Github Pull-Request [GH-649] was closed:
https://github.com/doctrine/doctrine2/pull/649

Comment by Marco Pivetta [ 21/Apr/13 ]

merged





[DDC-2404] Filter using join tables Created: 19/Apr/13  Updated: 21/Apr/13  Resolved: 21/Apr/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Filip Procházka Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 1
Labels: filter, filters, join, joins


 Description   

Allow filters to add join tables to sql queries for filtering.

Let's have Brand entity, and BrandText entity. Text is localisation for each Brand. If there is no BrandText with bt.isPublic and bt.web_id = 123 I wanna filter it globally and not even allow to load Brand entity.

This cannot be solved by using DQL, because I need to affect lazily loaded associations, for example in templates

Accessing $product->brand-> in template should resolve to NULL, when there is no BrandText.isPublic = 1.

This could be solved by allowing filters to add joins to queries. Should I prepare a pull request?



 Comments   
Comment by Oleg Namaka [ 21/Apr/13 ]

Duplicates http://www.doctrine-project.org/jira/browse/DDC-2220

Comment by Filip Procházka [ 21/Apr/13 ]

http://www.doctrine-project.org/jira/browse/DDC-2220





[DDC-2405] Changing strategy generates bad query. Created: 19/Apr/13  Updated: 21/Apr/13

Status: Reopened
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Van Rotemberg Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

For (unit, acceptance, functional) testing purpose I need to change the strategy of my GameStuff Entity class.

In previous version is was using php instruction below, but since doctrine orm 2.3, it doesn't work anymore.

$orm->getClassMetaData('Entities\GameStuff')->setIdGeneratorType(\Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_NONE);

will trigger:

Doctrine\DBAL\DBALException: An exception occurred while executing 'INSERT INTO vbank_accounts (game_id, updated_at, created_at) VALUES (?, ?, ?)' with params

{"1":1000010, "2":0,"3":"2013-04-19 17:16:05","4":"2013-04-19 17:16:05"}

:

SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens



 Comments   
Comment by Benjamin Eberlei [ 20/Apr/13 ]

The problem is that changing ClassMetadata after generating it from the cache is not really supported and depends on the Internal State of other classes. Have you tried creating a completly new EntityManager and then directly setting this? It could be that the SQL for the entity was already generated inside Doctrine, with the ID Generator information at IDENTITY_AUTO.

Comment by Van Rotemberg [ 21/Apr/13 ]

> The problem is that changing ClassMetadata after generating it from the cache is not really supported

Yeah, it is a problem indeed, why set ticket status to resolved ?
Do you think it's normal to have a public method that trigger a fatal error ?

Please fix it or put setIdGeneratorType as private, or AT LEAST add a context exception ...

Comment by Marco Pivetta [ 21/Apr/13 ]

Almost every interaction with metadata outside the `loadClassMetadata` event will cause unexpected problems. I don't think throwing an exception there helps in any way.

Comment by Van Rotemberg [ 21/Apr/13 ]

@marco pivetta

The generation of the actual exception comes from DBALException on the query excetion and point a bad generated query (Invalid parameter number),
when the problem comes from setting ClassMetada, and concerns a problem of cache generated after loadClassMetadata.

Adding an exception is just the fast way pointing where the problem comes from and that "setting metadata after loadMetadata is not supported anymore". (It will spare developper's time that used to set metadata, but also help future contribution)

> Please fix it or put setIdGeneratorType as private, or AT LEAST add a context exception ...
Note: BTW, my favorite solution would be to fix it (re-generate cache, or edit cache, or disable cache or whatever)





[DDC-2407] AbstractExporter _getIdGeneratorTypeString does not know about the UUID generator Created: 20/Apr/13  Updated: 20/Apr/13  Resolved: 20/Apr/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.3.3
Fix Version/s: 2.4

Type: Bug Priority: Minor
Reporter: Jeroen Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description