I created fixtures and some data was inserted many times without calling the Task entity PrePersist event listener.

I printed the used and generated hash and I saw a Proxies_CG_\Asitly\ProjectManagementBundle\Entity\User hash equal a Task entity hash!

If I have a query with a IN statement with more tahn 1000 values I get an sql error.

I've try IN with implode:
select * from test where id IN(' . implode(',', $values) . ')
and I've also try with executeQuery:
select * from test where id IN(:test)
executeQuery($sql, array($values), array(\Doctrine\DBAL\Connection::PARAM_INT_ARRAY))

This is a feature request.

Currently it is not possible to assign a detached entity to a relationship. You have to manually "merge" it, and only then you are able to assign it to relationships of managed objects.

This can become complicated to do. The way it is now, when assigning an entity to a relationship in a process using a large number of entities, the entity's state needs to be checked and the entity possibly merged - all in userland code. This adds a level of complexity and potential for errors, while it could be solved transparently and elegantly within the ORM. There are ways to implement it in userland code, too, with moderate effort (see below), but this does not change the fact that responsibility for implementing a purely technical feature is delegated to the user, who could be spending his time much better writing business code. And if the user actually implements it, it will clutter the application with non-problem-domain code.

To keep things simple, I propose Doctrine be extended to simply auto-merge any detached entities passed to it. That would save the programmer the manual tracking of object states and merge() calls.

This would be especially handy when using cascades, as keeping track of deep object graphs in userland code would duplicate substantial ORM functionality.

In programs that work with massive amounts of data, it is practically impossible to keep all entities managed due to resource constraints (see e.g. the batch processing patterns documented in the Doctrine 2 reference at http://www.doctrine-project.org/projects/orm/2.0/docs/reference/batch-processing/en). In a situation like that, one would probably simply flush and clear the entity manager regularly. Doctrine 2 currently forces the user to manually "merge" all persistent objects he/she still holds references to and wants to assign e.g. to other newly created persistable objects. I can not think of any reason why Doctrine 2 should not be able to do it automatically.

Below is another comment originally attached to the GitHub proposal, containing a userland implementation of the feature as a temporary fix, for whoever cares.

Here is a userland implementation for the functionality I am proposing, though I feel it is technical clutter that belongs into the ORM. Changing doctrine to be able to auto-merge unmanaged entities would be ideal. I thought I'd share this, for use as long as Doctrine 2 does not provide equivalent functionality. The implementation assumes all entities inherit from a base class (named "YourEntityBaseClass here") and intercepts the assignment to ToOne-relationships in a __set() method provided in that base class. For ToMany-relationships we extend ArrayCollection to intercept calls to add() and set() to accomplish the same.

As an alternative to defining a __set() method in a base class you could also implement the interception by changing any mutator methods you define in your entities. But that would bloat your code quickly as you define more and more relationship attributes on your entities.

The following __set() method implementation relies on reflection to parse the DocBlock-Comment with the Annotation and determine whether or not the property to be set is a ToOne-relationship.

   public function __set($name, &$value) {
      
      $reflectionClass = new ReflectionClass($this);
      
      $property = $reflectionClass->getProperty($name);

      if (   self::isToOneRelationship($property)
          && $value !== null) {
            
         $value = self::mergeIfDetached($value);
      }
      
      $this->$name = $value;
   }

The following is an implementation of mergeIfDetached(), that assumes there is a __get defined on the entity, to be able to access the protected mapped properties.

public static function mergeIfDetached(YourEntityBaseClass $dataObject) {

   $doctrineEntityManager = DB::getDoctrineEntityManager();

   if ($doctrineEntityManager->getUnitOfWork()->getEntityState($dataObject) == \Doctrine\ORM\UnitOfWork::STATE_DETACHED) {
       
      $dataObject = $doctrineEntityManager->merge($dataObject);
   }

   return $dataObject;
}

For your purposes, consider DB to be just a class holding a reference to the Doctrine entity manager.

Here are the helper methods for the reflection:

   private static function isToOneRelationship(ReflectionProperty $property) {

      return self::matchDoctrineAnnotation($property, self::$doctrineToOneRelationshipAnnotation);
   }

   private static function matchDoctrineAnnotation(ReflectionProperty $property, $pattern) {
      
      return preg_match('/\@' . $pattern . '/', $property->getDocComment()) != 0;
   }

Here is the drop-in-replacement class for use with ToMany-Relationships. It uses the static reloadIfDetached method defined in the entity base class:

use Doctrine\Common\Collections\ArrayCollection;


class Collection extends ArrayCollection {
   
    public function set($key, $value) {
       
       $value = YourEntityBaseClass::mergeIfDetached($value);
       
       parent::set($key, $value);
    }


    public function add($value) {
       
       $value = YourEntityBaseClass::mergeIfDetached($value);
       
       return parent::add($value);
    }
}

This approach keeps the amount of unnecessary code to a minimum, so that merges are not scattered throughout the problem-domain code.

Some ORM systems support an alternative to fetch-join queries, called a "query-join". See http://www.avaje.org/ebean/introquery_joinquery.html.

A query-join accomplishes the same as a fetch-join (hydrating a larger object graph across all associations types) but executes more than one SQL query in sequence in order to hydrate the requested portions of the graph in a result set. The first query retrieves data from the base entity/table and the next queries retrieve the data for the requested associations.

In some cases this approach is more efficient to a fetch-join:

(1) No data duplication in the SQL result as occurs in a fetch-join on to-many associations. Instead, this data is loaded through a second query. This saves network traffic, memory and general overhead in hydrating the returned results. In the case where large TEXT data is included in result sets, the savings here may be substantial.

(2) setFirstResult() and setMaxResult() are again effective (for pagination) and more importantly more efficient on these query-joins. The current DoctrineExtension solution to enable pagination on fetch-joins requires a series of queries to determine the target primary keys of the root entity of the query. The primary key lookup query requires DISTINCT or GROUP BY – which often triggers filesorts, temporary tables, etc (at least on MySQL) and greatly slows down the query. Query joins would not require this.

Possible implementation example:

// existing fetch-join
$query = $em->createQuery('SELECT c, o FROM Customers c JOIN c.orders o');
$query->setFirstResult(10)->setMaxResult(20); // doesn't do what you'd hope it would do, no ability to use this for pagination
$customersAndOrders = $query->getResult(); // array of Customer objects with Orders hydrated

// proposed query-join
$query = $em->createQuery('SELECT c, o FROM Customers c QUERY JOIN c.orders o');
$query->setFirstResult(10)->setMaxResult(20); // now works for pagination
$customersAndOrders = $query->getResult(); // array of Customer objects with Orders hyrdated
// this would execute a series of queries -- i.e. in SQL
// SELECT ... FROM customers LIMIT 10, 20
// SELECT ... FROM orders WHERE customer_id IN (.....)

and/or, could there be a way to trigger a "query-join" against an existing array of entities? for example

$query = $em->createQuery('SELECT c FROM Customers c'); // single query to fetch customers
$customers = $query->getResult(); // array of Customer objects
$em->join($customers, 'orders'); // fetch and hydrate the 'orders' association on each Customer using a single query

Perhaps at some point in the future Doctrine/DBAL could even make use of asynchronous queries (i.e. mysqlnd supports this) to allow these query-joins to run in parallel and the result would be more efficient paginated resultsets.

Thoughts/feedback?

postPersist/postUpdate events are triggered in the middle of a unitOfWork, and querying the DB in such events causes infinite loops. Doctrine attempts to flush the entity manager before running any query, which triggers flushing of entities, and postPersist/postUpdate events are triggered again.

I did not checked, but the flush() before each query may be a performance problem too, if doctrine has to determine what has changed, depending on the changetracking policy.

Also, it would be great if postPersist / postUpdate events were triggered after all entities have been persisted. It looks like that entities are flushed by groups of same 'type', and that events for a type are triggered once all of the elements of that group have been flushed, potentially before entities of an other type have been flushed : postPersist / postUpdate events are triggered while some other entities are still not flushed.

Currently the Doctrine\ORM\Configuration instance is not immutable after construction of the EM, which can lead to funny behavior when changing essential dependencies such as caches or others.

How do you look at adding findByIds(array $ids) to EntityManager and UnitOfWork? This would allow fetching multiple entities from a database at one request and would be very useful for caching - there would be even some kind of IdentityMap kept in memcached or any other caching engine, that supports multiple id retrieval: i've been using such an architecture in multiple projects and it turned out to be very effective. There were two basic methods - findIdsByFilter(array $filter) and findEntitiesByIds(array $ids). The latter one had a caching proxy, replicating entities to a cache storage. If this idea proceeds - I'd be glad to cover it with more details.

This topic on StackOverflow could also help:
http://stackoverflow.com/questions/276709/design-pattern-for-memcached-data-caching

Whenever a Proxy is generated it does not copy the docblocks.

This means when you do something like "$refl = new ReflectionObject($proxy)" you might be in trouble.

However if we add docblocks then we have to make sure that proxies do not magically appear as entities by throwing an exception in the AnnotationDriver.

Short: This issue is all about being able to use doctrine with naked domain objects without any use of doctrine classes.
I 'm not talking about PersistentCollection here, fully aware of that being tied into Doctrine, but those are injected, this is all about code dependency on ArrayCollection.

Seems like some of the UnitOfWork code is cable of handling other types of arrays, like:

    // If $actualData[$name] is not a Collection then use an ArrayCollection.
    if ( ! $actualData[$name] instanceof Collection) {
        $actualData[$name] = new ArrayCollection($actualData[$name]);
    }

But in __cascade* functions this is not the case in all but two:

    if ($relatedEntities instanceof Collection) {
        if ($relatedEntities instanceof PersistentCollection) {
            // Unwrap so that foreach() does not initialize

2 however have:

    if (($relatedEntities instanceof Collection || is_array($relatedEntities))) {
        if ($relatedEntities instanceof PersistentCollection) {
            // Unwrap so that foreach() does not initialize

Would it be an idea to do "instanceof Traversable" instead of " instanceof Collection"?

For usage with the foreign key as primary key features described in DDC-117 a derived id generator would be tons of useful. It is essentially a post generate id generator (sort of late pre insert though) assigned generator.

This is a contingency issue for https://github.com/doctrine/doctrine2/pull/60

"Fix to allow for proxy generated classes to respect methods in parent which may use func_get_args internally. Previously they would be passed nothing and thus fail. Also reduces need to build up argumentString. "

Hi there,
I'm trying to insert an encrypted data:

Because '"INSERT statements are not allowed in DQL, ...." i processed like this:
<?php
...
// controller
$membre = new \Entity\TMembre();
$membre->setPassword($password);
$em->persist($membre);
$em->flush();
...
?>
//entity
<?php
namespace Entity;
/**

• TMembre
  *
• @Table(name="t_membre")
• @Entity(repositoryClass="Repository\TMembreRepository")
  */
  class TMembre
  {
  /**
• Set password *
• @param string $password */
  public function setPassword($password) { $this->email = "AES_ENCRYPT('".$email."','"._MYSQL_CRYPT."')"; => insert this entire string without executing encryption $this->email = new \Doctrine\ORM\Query\Expr\Func("AES_ENCRYPT",array("'".$email."'","'"._MYSQL_CRYPT."'")); => does not work }

  }
  ?>

How can i do ?
Add this method to Doctrine\ORM\Query\Expr class ?

/**
public function aesEncrypt($value)

Best regards

David

Given two databases, 'foo' and 'bar', with entities in /Entities/Foo/ annotated as follows:

/**
 * Test
 *
 * @Table(name="foo.test")
 * @Entity
 */

Create an EntityManager instance with

$connectionOptions = array( 
    'dbname' => 'Foo', 
    'driver' => 'pdo_mysql', 
    <..etc..>
);

Use EntityManager#getClassMetaData( "Entities\\Foo
Test" ) to pass to SchemaTool#createSchema() and Doctrine appropriately creates a database table foo.test

Use EntityManager#getClassMetaData( "Entities\\Foo
Test" ) to pass to SchemaTool#updateSchema() and Doctrine fails with Exception
-> SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'test' already exists

Inserting

die( print_r( $fromSchema, 1 ) . print_r( $toSchema, 1 ) . print_r( $schemaDiff, 1 ) );

into Doctrine/ORM/Tools/SchemaTool.php line 632 shows $fromSchema outputs

[_tables:protected] => Array
        (
            [test]

but $toSchema outputs

[_tables:protected] => Array
        (
            [foo.test]

which causes $schemaDiff to output

[newTables] => Array
        (
            [foo.test]

In summary, Doctrine/DBAL/Schema/Comparator considers foo.test a new table, because Doctrine/DBAL/Schema/AbstractSchemaManager lists its table as "test" rather than "foo.test".

on page http://www.doctrine-project.org/docs/orm/2.0/en/reference/working-with-objects.html
section : 8.1. Association Example Entities, first example. Please see the .jpg in attachement(it explains clearly what I think is an error)
Regards.

To ensure that the MsSQL-Server 2005 (and maybe higher) uses the format that is specified in the MsSqlPlatform class (Y-m-d)
set it via 'SET DATEFORMAT ymd' .

This should be done directly after the connection has be opened.

It will help us use the namespace and code autocomplete in some IDE.

http://www.doctrine-project.org/docs/orm/2.0/en/reference/working-with-objects.html#entity-state

In the switch cases all the UnitOfWork constants are invalid.

Example:
UnitOfWork::NEW instead of being UnitOfWork::STATE_NEW

Sometimes a developer needs to issue a query without a FROM clause. This especially occurs using the QueryBuilder, when you may or may not have a table to select from, but call a stored procedure always.

Example:

$query = $em>createQuery('SELECT (1+1)');

The above query fails because the lexer expects T_FROM. If you replace (1+1) with a stored procedure, this example makes more sense.

One might argue about that you should use DBAL directly, but I disagree, because it always can happen that you end up in a situation like this:

$qb = $em->createQueryBuilder();

$qb->select("SOMEFANCYPROCEDURE()");

if ($condition) {
  $qb = $qb->from("additionalTable t");
}

This ticket aggregates several strategies to optimize batching of eager selects.

The UnitOfWork does not handle the case very well where a rollback is necessary. Can this be optimized?

Suppose a situation where:

A -> B

Where the OneToOne unidirectional association contains cascade persist.

If I decide to save an entity B that should create an A instance, it goes into maximum nesting level no matter if I track prePersist or postPersist.

We are using several Doctrine managers in our project with the same entity classes and different database tables.

The problem appears when we are willing to merge entity with lazy associations from one manager to another. The second entity manager instance hasn't got the proxy object metadata defined yet so it fails with Doctrine\ORM\Mapping\MappingException exception "Class EntityProxy is not a valid entity or mapped super class.".

If both entity managers share the proxy objects the problem can be fixed by calling

$em->getProxyFactory()->getProxy('Entity', -1);

which will register the entity metadata for the proxy classname as well.

Still if the proxy configuration differs, there is no fix found without changing the Doctrine ORM code.

The fix inside the Doctrine would be to detect Proxy classes before loading the metadata and load the metadata for it's parent class instead. Please see the diff attached with proposed solution.

Also I think this issue could arise when unserialized entity objects will be merged into the entity manager. I will try creating test case for this.

This is for those that know what they are doing

collection->get($key)

Atm in 2.1.2 this is loading the entire collection. It would be really handy that it would extra lazy load only one item using the association and indexBy fields and given key value (if collection is not initialized and the key havent been loaded yet ofc)

Am i making sense with this?

Lazy loading does not work for the relationships of an instance of an entity, whose class inherits from another entity class.

Assume there are two entity classes, A and B, where A inherits from B.

Now let $a be an instance of A, e. g. the result of "SELECT a FROM \A WHERE a.id = 1".

Outputting $a will confirm it is a valid instance of a proxy object inheriting from A.

Assume that the database row corresponding to $a contains a non-null foreign key that actually links to an existing row in another table, corresponding to another entity instance of a different class.

Now, $a->someRelationship will always returns null in this scenario. I assume this is unintended behaviour, because clearly, the other entity should be lazily loaded on accessing it, and there is a value in the database.

The fetch annotation attribute on that relationship has not been explicitly set, so I assume it is set to the default value, which, according to the docs, should be "lazy".

The loading only fails when accessing the relationships of an entity instance, whose class inherits from another entity class. For entity instances, whose classes do not inherit from another entity class, lazy loading of their relationships works as expected.

I had a look at the proxy objects and verified that they are present and override the __get method with an implementation containing a call to the load() method. Still, the loading won't work for some reason.

This could be related to Bug DDC-1389 (http://www.doctrine-project.org/jira/browse/DDC-1389) which also happens exclusively in an inheritance scenario. Maybe the current implementation of inheritance is generally wrong or incomplete.

see https://github.com/doctrine/doctrine2/pull/125

Consider this example:

select g.id, u.id, u.status, count(p.phonenumber) numPhones from Group
     * g join g.user u join u.phonenumbers p group by g.id, u.status, u.id

With data:

phonenumbers:
    [1, 2, 3, 4, 5, 6]
users:
    [{id: 1, status: developer, phonenumbers: [1, 2]},
     {id: 2, status: developer, phonenumbers: [3]},
     {id: 3, status: developer, phonenumbers: [4, 5, 6]}]
groups:
    [{id: 1, users: [1, 2]]},
     {id:2, users: [3]}]

The result currently is:

array(
    array(
        0 => object(CmsGroup) {
            'id' => 1,
            'users' => Collection(
                object(CmsUser) { 'id' => 1 },
                object(CmsUser) { 'id' => 2 }
            )
         },
        'numPhones' => 1
    ),
    array(
        0 => object(CmsGroup) {
            'id' => 2,
            'users' => Collection(
                object(CmsUser) { 'id' => 3 }
            )
        },
        'numPhones' => 3
    )
)

Note that the first entry contains only one value numPhones => 1, even though there are two users associated with that group. One of whom has 2 phone numbers and the other has 1.

The result I would expect is:

array(
    array(
        0 => object(CmsGroup) {
            'id' => 1,
            'users' => Collection(
                object(CmsUser) { 'id' => 1 },
                object(CmsUser) { 'id' => 2 }
            )
         },
        'numPhones' => array(2, 1)
    ),
    array(
        0 => object(CmsGroup) {
            'id' => 2,
            'users' => Collection(
                object(CmsUser) { 'id' => 3 }
            )
        },
        'numPhones' => array(3)
    )
)

The difference is that numPhones for each row now contains an array of the
scalar values matching the corresponding users.

BasicEntityPersister::load() calls:
$stmt = $this->_conn->executeQuery($sql, $params, $types);
on line 665 of master/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php

The executeQuery function has an optional fourth parameter to pass a QueryCacheProfile variable to use caching on the query. This is ignored/not implemented by BasicEntityPersister::load()

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/tutorials/getting-started.html
in file create_bug.php
$bug->setDescription("Something does not work!");
but the class Bug do not have setDescription function.

ps:
try find "setDescription" on that page. there is only one .

As I sayd in the title, it would be nice if the ORM layer could permit to map a 1:n association in the db as an unidirectional OneToMany in the classes, without using a JoinTable in the database.
This would permit us to get rid of the unnecessary database JoinTable, which creates disorder and decreases performance for no valuable reason.

Is it possible?

While associating object to an descriminated table I wasn't enable to fix the entityTarget (only one can be set in entity annotation).

It could be resolve by adding the possibility to override 'targetEntity' value in Doctrine\ORM\Mapping\ClassMetadataInfo::ClassMetadataInfo().

Such as :

if (isset($overrideMapping['targetEntity'])) {
$mapping['targetEntity'] = $overrideMapping['targetEntity'];
}

That would need to add a control on the new targetEntity in Doctrine\ORM\Mapping\ClassMetadataInfo::_validateAndCompleteAssociationMapping().

Such as :

if ( ! ClassLoader::classExists($mapping['targetEntity']) ) {
throw MappingException::invalidTargetEntityClass($mapping['targetEntity'], $this->name, $mapping['fieldName']);
}

cro.

This is the closeCursor() method in DBAL\Cache\ResultCacheStatement.php:

public function closeCursor()
    {
        $this->statement->closeCursor();
        if ($this->emptied && $this->data !== null) {
            $data = $this->resultCache->fetch($this->cacheKey);
            if ( ! $data) {
                $data = array();
            }
            $data[$this->realKey] = $this->data;

            $this->resultCache->save($this->cacheKey, $data, $this->lifetime);
            unset($this->data);
        }
    }

We are using Memcache and I noticed an extra GET operation on all cache misses. In the code above I believe the fetch call is not necessary and that the code would do the same without it.
Also, may I ask why is the SQL used as a key in the cached data?

createQueryBuilder() currently doesn’t have a parameter to set the third option on the FROM fragment: indexBy. Right now you have to read it, create a new From with the read properties and your desired indexBy value and replace the existing one on the QueryBuilder.

Should be ten minutes’ work including tests. Thanks a lot!

I tried to use the findBy method with limit and offset parameters against an Oracle database using oci8 driver.

The query seems to executed successfully but the hydrator fails when hydrating data as there is a DOCTRINE_ROWNUM column appending the "limit" clause.

Here is the exception thrown : "Notice: Undefined index: DOCTRINE_ROWNUM in [...]/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/SimpleObjectHydrator.php line 183"

I was thinking about something like this to fix this issue :

• add an attribute (platformExtraColumns) to the platform class, storing every column added by methods like doModifyLimitQuery
• check in hydrator method hydrateRowData if the column exists among the extra columns attribute of the custom platform
• don't use the column if true

Maybe there is a better approach, what are your thoughts?

@ORM\Table(name="applications", indexes={@ORM\Index(name="csl_idx", columns=

), @ORM\Index(columns=

), @ORM\Index(columns=

)})

index-names not specified Symfony2 schemaUpdate tools shows only the last Index

UoW currently passes computed changesets to lifecycle event args byref. This has to be changed to force users to use UoW public API to modify changesets instead.

Using a simple Testcase like in http://docs.doctrine-project.org/projects/doctrine-orm/en/2.1/reference/native-sql.html there are two Tables:

*) users:

   Column   |  Type   | Modifiers | Storage  | Description 
------------+---------+-----------+----------+-------------
 u_id       | integer | not null  | plain    | 
 u_name     | text    | not null  | extended | 
 address_id | integer | not null  | plain    | 

*) address:

  Column  |  Type   | Modifiers | Storage  | Description 
----------+---------+-----------+----------+-------------
 a_id     | integer | not null  | plain    | 
 a_street | text    | not null  | extended | 
 a_city   | text    | not null  | extended | 

address_id is a foreign key to address;

Now i created the Entities and setup a native query using ResultSetMappingBuilder:

$rsm = new \Doctrine\ORM\Query\ResultSetMappingBuilder($entityManager);
$rsm->addRootEntityFromClassMetadata('MyProject\Entity\Users', 'u');
$rsm->addJoinedEntityFromClassMetadata('MyProject\Entity\Address', 'a', 'u', 'address');

$query = '
    SELECT
        u.*,
        a.*
    FROM
        users u
    LEFT JOIN address a ON (u.address_id = a.a_id)
';

/** @var $native \Doctrine\ORM\NativeQuery */
$native = $entityManager->createNativeQuery($query, $rsm);

$ret = $native->getResult();

This returns the Entities correctly:

array(2) {
  [0] =>
  class MyProject\Entity\Users#61 (3) {
    protected $id =>
    int(1)
    protected $name =>
    string(5) "Smith"
    protected $address =>
    class MyProject\Entity\Address#63 (4) {
      protected $id =>
      int(1)
      protected $street =>
      string(8) "Broadway"
      protected $city =>
      string(8) "New York"
      protected $users =>
      class Doctrine\ORM\PersistentCollection#64 (9) {
        ...
      }
    }
  }
  [1] =>
  class MyProject\Entity\Users#66 (3) {
    protected $id =>
    int(2)
    protected $name =>
    string(7) "Sherlok"
    protected $address =>
    class MyProject\Entity\Address#67 (4) {
      protected $id =>
      int(2)
      protected $street =>
      string(13) "Oxford Street"
      protected $city =>
      string(6) "London"
      protected $users =>
      class Doctrine\ORM\PersistentCollection#68 (9) {
        ...
      }
    }
  }
}

BUT if you change the order of the select columns starting with ones from address you get borked Data:

$query = '
    SELECT
        a.*,
        u.*
    FROM
        users u
    LEFT JOIN address a ON (u.address_id = a.a_id)
';

array(2) {
  [0] =>
  class MyProject\Entity\Users#61 (3) {
    protected $id =>
    int(1)
    protected $name =>
    string(5) "Smith"
    protected $address =>
    class MyProject\Entity\Address#63 (4) {
      protected $id =>
      int(2)
      protected $street =>
      string(13) "Oxford Street"
      protected $city =>
      string(6) "London"
      protected $users =>
      class Doctrine\ORM\PersistentCollection#64 (9) {
        ...
      }
    }
  }
  [1] =>
  class MyProject\Entity\Users#66 (3) {
    protected $id =>
    int(2)
    protected $name =>
    string(7) "Sherlok"
    protected $address =>
    NULL
  }
}

This happens because the function Doctrine\ORM\Internal\Hydration\AbstractHydrator::_gatherRowData does not consider the Mapping i set up. Instead it just add the columns as they get starting with address ones.

Doctrine\ORM\Internal\Hydration\ObjectHydrator::_hydrateRow then knows the Mapping and ignores the first Address as there is no User to map on, cycling to the next row will then add the address of the second row to the user from the first one.

There are multiple ways to fix this. One would be to consider the mapping in _gatherRowData, the second to rewrite the _hydrateRow generating the Entities first and then the mapping in a second foreach loop.

This bugger had me for 2 days until i finally figured it out.

thanks

The WITH Keyowrd is appended to the whole FROM .. JOIN .. block instead of behind the FROM block.

Is there any particular reason why onFlush event is not triggered when the transaction is allready open? https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L290 It would help a lot developing listeners since this event is the mostly used one and since theres preFlush now it seems a logical solution if onFlush would be a start of transaction in general

Testing the new Doctrine 2.2 Beta we finally got the postFlush event which is a nice way to handle things after all the DB work has finished. The main problem is that there is no way to get all the flushed entities. In the onFlush event you are able to use the getScheduledEntityUpdates/Inserts/Deletions but as these entities are flushed, those arrays are now empty. To solve this i see 2 aproaches:

1. Not unseting the array that holds the scheduled entities so the getScheduledEntityUpdates/Inserts/Deletions still have data. Those arrays are reset just before finishing the commit method so maybe unsetting them one by one as they are flushed is not necessary
2. Unset the arrays but at the same time, fill another "flushedEntities" array with the flushed entities and then be able to get that array with a getFlushedEntities method

I can make a patch if necessary, just wanted to know if that sounds ok before starting it

As i understand the documentation correctly, orphanRemoval associations have the meaning of a "part of" relationship. In the example (http://www.doctrine-project.org/docs/orm/2.0/en/reference/working-with-associations.html#orphan-removal) the adresses are part of the contact.

In my opinion we should reason that the state of the adress consists of the states of all nested contacts. As a consequence we should flag the contact as "dirty" when the adresses change.

This is relevant for optimistic locking scenarios or event handlers. In my application i tried to use optimistic locking for "contacts", which does not work if i don't change anything in the contact but only in the nested addresses.

/**
 * @ORM\Entity
 */
class Top
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;
    /**
     * @ORM\OneToOne(targetEntity="LevelOne", orphanRemoval="true", cascade={"persist", "remove"})
     */
    protected $levelOne;
    
    public function getId()
    {
        return $this->id;
    }

    public function setLevelOne(LevelOne $levelOne)
    {
        $this->levelOne = $levelOne;
    }

    public function getLevelOne()
    {
        return $this->levelOne;
    }
}

/**
 * @ORM\Entity
 */
class LevelOne
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;
    /**
     * @ORM\OneToOne(targetEntity="LevelTwo", orphanRemoval="true", cascade={"persist", "remove"})
     */
    protected $levelTwo;

    public function getId()
    {
        return $this->id;
    }
    
    public function setId($id)
    {
        $this->id = $id;
    }

    public function setLevelTwo(LevelTwo $levelTwo)
    {
        $this->levelTwo = $levelTwo;
    }

    public function getLevelTwo()
    {
        return $this->levelTwo;
    }
}

/**
 * @ORM\Entity
 */
class LevelTwo
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;
    
    public function getId()
    {
        return $this->id;
    }
    
    public function setId($id)
    {
        $this->id = $id;
    }
}

trying to clone objects

$top = new Top();
        $top->setLevelOne(new LevelOne());
        $top->getLevelOne()->setLevelTwo(new LevelTwo());
        
        $this->em->persist($top);
        $this->em->flush();
        
        $newTop = new Top();
        $newTop->setLevelOne(clone $top->getLevelOne());
        $newTop->getLevelOne()->setId(null);
        $newTop->getLevelOne()->getLevelTwo()->setId(null);
        
        var_dump($newTop->getLevelOne()->getId());
        var_dump($newTop->getLevelOne()->getLevelTwo()->getId());
        
        $this->em->persist($newTop);
        $this->em->flush();

the output is:
NULL
NULL
[PDOException]
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' for key 'UNIQ_82A72CD0778BC57F'
(it duplicates level two entity)
I worked for a while with entities, in a certain set of entity properties it completely persisted into database, but without relation between level one and level two.

I'm making an access control system and would like to automatically filter all queries based current user, targetEntity type and query type. Query type is relevant as different permissions are needed by the user for SELECT, UPDATE, DELETE and INSERT queries.

I can access the first two things in my filter easily enough, but I cannot find a way to have the filter know what type of query the filter is being applied to.

The method getResultCacheId of Doctrine\ORM\AbstractQuery should be public.

I'm trying to customize the cache refresh mechanism to clear previously cached objects in my app.
To do that I'm adding a prefix to define regions in the cache.
To be able to set the Id's correctly (adding region prefixes) I need to get the "normal" hash doctrine were used in the normal scenario (trying to avoid introduce new code).
That's why I will prefer the method to be public.

When merging a graph of detached entities, the created entitied are created and the updated entities are updated but the non-present entities (which exist in the database but are not in the graph) are neither removed nor have them their association column nullified.

Example :

In my code I have 2 entities : Parent and Child. There is a OneToMany(cascade=

, orphanRemoval=true) relation defined in Parent.

In my database I have a Parent row with an id of 1, which has 3 Children with ids 1,2,3.

When I write the following code, I expect the Parent with id 1 and the Child with id 2 to be updated, a new Child to be created and the Child with id 1 and 3 to be deleted.

$parent = new Parent(); $parent->id = 1  // detached entity
$existing_child = new Child(); $child->id = 2 // detached entity
$new_child = new Child(); // new entity
$dinner->addChild($existing_child);
$dinner->addChild($new_child);

$em->merge($dinner);

$em->flush();

The objects I expect to be created and updated have the correct behaviour but the old children are not touched, they are still present in the database.

The schema validator should analyze mapped lifecycle callbacks and:

a) if some lifecycle callbacks were defined, but no @HasLifecycleCallbacks annotation/mapping was set, warn the user
b) if some lifecycle callbacks were defined, but methods are not public, warn the user

When running following DQL in newly cleared EntityManager, with the provided entities (see attached archive or gist at https://gist.github.com/2473775 ), results in different fetched association:

DQL without join:
SELECT a FROM Entity\A a WHERE a.id = :id

SQL without join:
SELECT a0_.a_id AS a_id0, a0_.id AS id1 FROM a a0_ WHERE a0_.a_id = ?

Result without join:
$query->getOneOrNullResult()>getB()>getName(); // 'correct'

DQL with fetch join:
SELECT a, b FROM Entity\A a LEFT JOIN a.b b WHERE a.id = :id

SQL with fetch join:
SELECT a0_.a_id AS a_id0, b1_.id AS id1, b1_.name AS name2, a0_.id AS id3 FROM a a0_ LEFT JOIN b b1_ ON a0_.id = b1_.id WHERE a0_.a_id = ?

Result with fetch join:
$query->getOneOrNullResult()>getB()>getName(); // 'wrong' (different result)

The problem seems to be strictly related with how the `@JoinColumn` is configured.

I use a dql query where I bind a named parameter 2 time in the same query for different joined fields. The query work but the count query failed saying that there are missing bind variable.

ex:
$qb = $this->getQueryBuilder()
->select('
partial fl.

,
partial fla.

,
partial ds.

')
->from('Fo_Listing', 'fl')
->join('fl.listing_properties', 'flp')
->join('flp.property', 'fp')
->leftjoin('fl.listing_assets', 'fla')
->leftjoin('fla.asset', 'ca')
->leftjoin('ca.ds', 'ds')
->where('fp.id = :propertyId')
->setParameter('propertyId', $id)
->andWhere('fl.object_status_id <> :deleted')
->setParameter('deleted', CoRefObjectStatus::DELETE)
->andWhere('fl.publishing_status_id = :published')
->setParameter('published', CoRefPublishingStatus::PUBLISHED)
->andWhere('fp.object_status_id <> :deleted')
->setParameter('deleted', CoRefObjectStatus::DELETE)
->andWhere('fp.publishing_status_id = :published')
->setParameter('published', CoRefPublishingStatus::PUBLISHED)
->add('orderBy', 'fl.listing_date DESC, fl.published_date DESC')
->setMaxResults($onTheMarketLimit);

$onTheMarket = new Paginator($qb, $fetchJoin = true);

To make it work, I've renamed the second usage of the named variable with a 2 at the end. deleted2 and published2.

Think of a joined subclass inheritance setup where abstract base class A has many concrete child classes C1 ... CN. For each child class a table necessarily has to created. Yet if there are many child classes not defining any additional fields you will get many "id only" child tables. This leads to unnecessary join and insert overhead on database operations as well as a bunch of quite senseless tables in your schema that need to be maintained.

While there are already tickets requesting support for mixed inheritance mapping (e.g. DDC-138) I want to propose another - obviously easy to implement - solution that addresses the "id only table" problem. The basic idea is to extend ClassMetadata by a flag "hasOwnTable" which is true by default and applicable for child classes of a joined subclass tree. Setting this flag to <false> would lead to...
1.) no child table creation for corresponding model
2.) no joins to this table while rendering SQL from DQL statements
3.) no INSERT, UPDATE and DELETE statements for this table in methods executeInserts(), update() and delete() on Doctrine\ORM\Persisters\JoinedSubclassPersister.

(3) can easily be implemented since the mentioned methods all loop on ClassMetadata::parentClasses. For those classes which set the flag "hasOwnTable" to false the operation will be skipped. On the other hand (2) doesn't seem to a big deal either. Extending SqlWalker::_generateClassTableInheritanceJoins() by means of a flag test seems to be enough. Of course setting the flag to <false> while defining additional fields on child class level must be rejected.

If you go for this feature I would be pleased to provide an implementation.

Some Oracle customer databases are set up having different settings for their "DBNAME" and "SID" / "SERVICE" property. (DBNAME != SID)

So, hereing it's currently not possible to connect via the PDO_Oracle driver (Class: Doctrine\DBAL\Driver\PDOOracle\Driver) as it uses the DBNAME value by default as value for SID / SERVICE in the _constructPdoDsn() method. (DBNAME = SID)

A solution would be to add an additional config param like "servicename" and pass it's value into _constructPdoDsn().

An updated version of the method could look like:

private function _constructPdoDsn(array $params)
{
$dsn = 'oci:';
if (isset($params['host']) && $params['host'] != '') {
$dsn .= 'dbname=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)' .
'(HOST=' . $params['host'] . ')';

if (isset($params['port']))

else

if (isset($params['servicename']) && $params['servicename'] != '')

else

if (isset($params['service']) && $params['service'] == true)

else

} else

if (isset($params['charset']))

return $dsn;
}

The only workaround for me is right now to use the "standard" PHP OCI / OCI8 functions with the correct SID / Service in it's DSN.

The Query class should not be marked final as this makes it impossible to Mock it.

When we serialize entities in a session, we often have pointers to uninitialized proxies.
These proxies have $_entityPersister == null.

The problem is that if you happen to call by mistake a method on such a proxy, you're not aware that this is an uninitialized proxy, and the business methods are called, with null values for every property.

I think the proxy should throw an exception in that case.
Attached, a patch with the proposed modification.

i am not able to extract only month from the date field using doctrine2 using 'MONTH' function

In decoupled applications the model layer returns "data-transfer-objects" through the boundary into the controller/view layer. It would make sense to have Doctrine directly generate any data-transfer/value-object from native and dql queries.

Example:
SELECT .... WHERE upper(n.title) LIKE upper(:filter)

should be a valid SQL, now is rejected because the walker only accept a variable or an string expression.

I'm adding a patch to address this.

This issue was originally discussed in http://www.doctrine-project.org/jira/browse/DDC-357

Say there is User and UserData with oneToOne bidirectional relationship. When we fetch User objects, UserData is lazy loaded right away.

If we were to set UserData 's id as asssosiationKey of User, then user_id becomes the id of UserData and User object can already know that UserData owning side's id will equal it's own User->id.

Can this be implemented?

I'm attaching a patch with the suggestion.

Starting with Doctrine 2.2, the Proxy classes have inconsistent naming with their file name, which raises problems with class autoloading.
For example, a class named Application\Model\User creates the following proxy class:

Application\Proxy\__CG__\Application\Model\User

This class is located in the following file:

Application/Proxy/__CG__ApplicationModelUser.php

But whe we serialize such an entity, then unserialize it in another session, the framework autoloader expects the class to be located in:

Application/Proxy/__CG__/Application/Model/User.php

But it is not.
As a result, a __PHP_Incomplete_Class is created instead of the expected proxy class.

I'm not sure whether this is an intended behavior, but I would assume this is a bug.

It would be great if Doctrine had the possibility to define a further inharitance in a subclass.

Example:
There is a class DataObject managing things like created- and lastedit-
timestamps, archiving objects before updates, ...
One of the sub-objects is Content.
There are several types of content.
Written directly to a database field, read from a textfile on server,
executed php file on server, loaded from another server via xmlrpc and
so on.

I'd like to use a single table inheritance to map all information of
the different content objects in one table.
If I understand the model right the only alternate solution would be
to write each single content object to the discriminator map of
DataObject.

A problem when working with collection-valued associations is that almost all operations except add($obj) require the collection to become initialized in order for the operation to be performed properly. While this is all correct and beautiful OO-wise it may be problematic at times with regards to performance. Hence we might want to consider to provide some convenient methods along the lines of link/unlink (name suggestions?) which allow more direct, less OO collection manipulation. Such methods obviously would bypass the normal object lifecycle and the changes done through these methods will not be reflected in the in-memory objects and collections, unless the user keeps them in-synch himself.