Doctrine Project

[DDC-274] Class and namespace naming inconsistency

Sun, 31 Oct 2010 05:20:55 +0000

There are inconsistencies with some class and namespace names that include acronyms.

Examples:

Classes with upper-casing:
ORMException, DBALException, OCI8Connection, etc.

Classes with proper-casing:
RunDqlTask, CliException, MySqlPlatform, etc.

Namespaces with upper-casing:
DBAL, ORM, Doctrine\DBAL\Driver\PDOMsSql, etc.

Namespaces with proper-casing:
Doctrine\Common\Cli, Doctrine\DBAL\Tools\Cli\, Doctrine\ORM\Id, etc.

There is more proper-casing than upper-casing. IMHO, proper-casing is better as it's easier to read "SqlException" than it is to read "SQLException" (the "E" looks like part of the acronym), and things like "CLITask" can be avoided.

I discussed this a bit with Benjamin and Guilherme, and they were unsure and said that the whole team needed to reach consensus.

I'm leaving the priority as "Major" because this should probably be fixed sooner rather than later to prevent compatibility breaks.

[DDC-851] Automerge of detached entities passed to doctrine

Thu, 30 Dec 2010 05:55:17 +0000

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.

[DDC-821] Consider adding Query-Join as another join method for DQL

Wed, 29 Dec 2010 00:49:46 +0000

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?

[DDC-810] Issue with detaching entities and updating when using change notification

Mon, 4 Jul 2011 21:47:46 +0000

Issue with detaching entities and updating when using change notification

[DDC-803] Create subselect queries within join statements

Tue, 14 Sep 2010 08:58:51 +0000

Create subselect queries within join statements

[DDC-785] Post-Post-Persist event

Fri, 14 Jan 2011 03:11:48 +0000

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.

[DDC-779] Doctrine\ORM\Configuration should be immutable after construction of EntityManager

Mon, 30 Aug 2010 16:23:27 +0000

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.

[DDC-769] Disabling discriminator column in WHERE clause

Tue, 7 Sep 2010 06:49:13 +0000

Per default Doctrine 2 adds an IN(...)-part to the query when hydrating an entity where a discriminator column is defined. While this makes sense as a default behavior, it would be pretty helpful if one could disable the WHERE-clause for discriminator columns alltogether for performance optimization.

[DDC-946] Evaluate optional use of igbinary for serialization

Wed, 22 Dec 2010 12:17:56 +0000

Igbinary is supposed to be faster and better than serialize/unserialize(). We should check if its relevant for us (metadata and query caching for example):

https://github.com/phadej/igbinary

[DDC-930] A table cannot have more than one many to many relationship with the same table when using reverse engineer

Mon, 13 Dec 2010 02:52:49 +0000

This is caused by taking the join column name as the identifier while generating a property name for annotation. The mapping driver detects that the same property is already defined and ends the convert process. A little bit smarter approach for me was to take the local table name. But this assumes a specific style of join table naming convention.

Doctrine\ORM\Mapping\Driver\DatabaseDriver::loadMetadataForClass()

Replace:

$associationMapping['fieldName'] = Inflector::camelize(str_replace('_id', '', strtolower(current($otherFk->getColumns()))));

With:

$name = explode("_",$myFk->getLocalTableName());
if (count($name) > 1)
{
array_shift($name);
}
$name = implode("_", $name);

$associationMapping['fieldName'] = Inflector::camelize(str_replace('_id', '', strtolower($name)));

Maybe to switch to this behavior with an additional option?

[DDC-919] subselect

Sun, 20 Mar 2011 13:45:51 +0000

i'd like to see more example in documentation with this subselects
[23:08] <beberlei> can you open a tciket on jira? then i dont forget to do that when i have time

[DDC-265] Possibility for Nested Inheritance

Duplicate — Wed, 16 Jan 2013 08:16:23 +0000

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.

[DDC-213] Persist order of collections

Duplicate — Tue, 16 Oct 2012 07:43:02 +0000

A Collection is like a php array, an ordered map. Hence there should be the possibility to persist this order.

[DDC-128] Consider adding EntityManager#link/unlink methods for direct association manipulation

Reference — Wed, 29 Dec 2010 06:32:36 +0000

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.

[DDC-586] Repo does not find "unflushed" object

Thu, 26 Aug 2010 08:01:27 +0000

The problem is this:

$bar = new \entity\content\ContentTag();
$bar->setName('bar');
$em->persist($bar);

$existingTag = $em->getRepository('entity\content\ContentTag')->findOneByName('bar');

Seeing as in EntityRepository "find()" queries the Unit of Work first, and "findBy()" goes directly to the persister, only remotely stored objects will be found. Now if I want a tag object to attach related tags, it would have to query by name to see if an object already exist, BUT it wont find one as the UoW has not been committed, resulting in a new one being created, ultimately resulting in a PDO error on the unique name constraint.

This can be "solved" by inserting a flush, but it is impossible to know whether a flush is required, without knowledge of what comes next. I.e. for one part to know it has to flush, it has to know another wants to fetch an object you just created.

This causes an unacceptable amount of coupling.

Somehow the repo will have to be able execute DQL against the objects in the UoW. This does not have to be full support (straight away), but it should fail (throw an exception) if the possibility exists that the UoW contains items that are excluded (e.g. the operation is not supported and the UoW still contains items).

For right now, this means the EntityManager should throw an exception if DQL is executed on the type when the UoW is not empty. Until the time that the EntityManager can query the UoW using DQL. The alternative would be to "flush" before every operation that goes to the database for data.

[DDC-536] Remove the _ prefix from private and protected members

Fri, 19 Nov 2010 00:00:39 +0000

The reasoning is simple: The prefix "_" is usually either used for easier distinction of instance variables from other, i.e. local variables, instead of always using "this." (often seen in C#), or it is used to signal that a member is not meant to be accessed from outside of the class when the language does not have visibility modifiers (PHP4).

Since you always have to use "$this->" in PHP5+ when accessing instance members and there are visibility modifiers, the "_" is largely superfluous and just makes the verbose OO code even more verbose.

Maybe the following find/replace steps will do the job almost completely:

"private $_" => "private $"
"protected $_" => "protected $"
"$this->_" => "$this->"

[DDC-687] Add New Entity Attribute "idGetter" to allow accessing the ID without triggering lazy-load

Tue, 25 Jan 2011 08:23:14 +0000

Often people present us with the use-case that they want to access the ID of a proxy without loading it.

This has lead to several ugly solutions like mapping the ID to an object and as a foreign key field. There currently exists a simple solution for this:

$id = $em->getUnitOfWork()->getEntityIdentifier($entity->getRelatedProxy());

However we could add a new property here called "idGetter" that would take the name of a method.

During Proxy Generation then this method is created with magic functionality that:

1. In case of Single Primary Key returns the single value
2. In case of Composite Primary Key returns an array of the values in their UoW internal order
3. Throw an Exception if the method does not exist on the original object

[DDC-688] Original Entity Data gets overridden by the change set

Tue, 28 Dec 2010 06:38:22 +0000

When changing data in an entity, the UnitOfWork will call computeChangeSet on a flush event. If there is a changeset, the original data ($this->_originalEntityData) gets overridden by the new data. However, the _originalEntityData should hold the original data, that was present at the time the entity was reconstituted from the database. This does no longer hold now.

I think this can simply be fixed by commenting this line, however I do not know of any consequences this may bring with it:

$this->_originalEntityData[$oid] = $actualData; (in computeChangeSet, after if( $changeSet ));

Anyway, I ran into this problem while trying to retrieve the original data at the onFlush event of an update.

[DDC-682] ORACLE CHARSET DOCUMENTATION

Sat, 10 Jul 2010 13:55:31 +0000

Openning an Oracle Database with Doctrine and Symfony doesn't support by default utf8 charset.

To support it, it is necessary to specify charset=AL32UTF8 in the dsn of the database in config/databases.yml. Analogous to the example shown at
http://groups.google.com/group/doctrine-user/browse_thread/thread/d0d22145d8bdc83
however we have been able to use it fully only with the oracle driver (instead of oci), for example:

oracle:dbname=//192.168.2.9:1521/nomina_dev;charset=AL32UTF8

Documentation by Alexia Velásquez (alexia.velasquez@hotmail.es, Vladimir Tàmara (vtamara@pasosdeJesus.org) and Fernando Guerrero

[DDC-678] OneToMany/OneToOne + onDelete=CASCADE may corrupt UoW.

Sun, 5 Jun 2011 15:15:44 +0000

OneToMany/OneToOne associations together with an onDelete=CASCADE schema generation hint on the @JoinColumn and appropriate foreign key constraints can potentially result in a corrupt UoW if the associated objects are already managed. We need to add tests for such scenarios and settle on a well-defined behavior in such cases.

[DDC-624] Partial object query that leaves out an association to avoid loading it fetches the association anyway.

Duplicate — Fri, 11 Nov 2011 09:28:13 +0000

Assuming:

Customer <onetoone> Cart

where Cart is the owning side.

Since the association from Customer to Cart can not be lazy, it would make sense to leave out the association in a query to avoid loading the carts like this:

select partial c.{id,name, ... anything except cart} from Customer c"

But this is ignored and the carts of all customers are fetched anyway. Query::HINT_FORCE_PARTIAL_LOAD is an alternative solution, however it has the disadvantage that it disables lazy-loading for all queried objects. If partial querying would honor associations this would allow more fine-grained control.

[DDC-138] Allow for mixed inheritance mapping

Duplicate — Fri, 24 Dec 2010 04:54:34 +0000

Requesting implementation of mixed inheritance mapping (class table inheritance and single table inheritance).

This would be especially handy when the difference between certain classes is only "implementational" (i.e. a subclass only functions differently/implements abstract methods and does not specify any additional fields). Using class table inheritance would result in tables only containing an id column.

[DDC-776] Persisters use a fixed "SELECT" SQL statements

Tue, 23 Apr 2013 12:09:39 +0000

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.

[DDC-349] Add support for specifying precedence in joins in DQL

Duplicate — Wed, 1 May 2013 18:46:53 +0000

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!

[DDC-878] Don't explicitly require object members (fields) to be defined in the entity class

Tue, 16 Nov 2010 13:12:24 +0000

Currently, Doctrine REQUIRES that a given entity class have protected or private members explicitly defined in the class (even if meta data mapping is handled elsewhere, such as in YAML). This is less than optimal...for example, many class implementations prefer to store all data in a protected $fields member, as an array, accessing the members with getters and setters.

Doctrine makes this behavior impossible. An exception is thrown if a field defined in meta data is not an explicit member of the class. Instead, it should 'take the meta data's word for it' that the field exists, and is accessible via getters and setters, without explicitly checking for the member. The meta data is already the authoritative source, I don't see why the double check should (or needs to) be performed (although I am not familiar with Doctrine internals). Since Doctrine recommends making members private, I have to assume it is already hydrating them with the get/set accessors anyway...so it should just rely on them.

Quick example use case (notice 'name' is not actually a member...it is stored in $fields and assume meta data is defined in a separate yaml file):

class User

{ protected $fields = array(); public function getName() { return $this->fields['name']; } public function setName($name) { $this->fields['name'] = $name; } }

[DDC-838] SchemaTool - ignores the attribute uniq in relations

Fri, 29 Oct 2010 09:23:04 +0000

Mapper

<entity name="Default_Model_Test" table="test">
  <id name="id" type="integer" column="id">
    <generator strategy="AUTO"/>
  </id>
  <field name="blabla" column="blabla" type="boolean"/>
  <one-to-one field="user" target-entity="Users_Model_User">
    <join-column name="users_id" referenced-column-name="id" on-delete="CASCADE" on-update="CASCADE" unique="false" />
  </one-to-one>
</entity>

SQL

CREATE TABLE test (id INT AUTO_INCREMENT NOT NULL, users_id INT DEFAULT NULL, blabla TINYINT(1) NOT NULL, UNIQUE INDEX test_users_id_uniq (users_id), PRIMARY KEY(id)) ENGINE = InnoDB;
ALTER TABLE test ADD FOREIGN KEY (users_id) REFERENCES users(id) ON UPDATE CASCADE ON DELETE CASCADE;

Actual:
UNIQUE INDEX test_users_id_uniq (users_id)

Expected:
INDEX test_users_id (users_id)

[DDC-935] copy function needs implementation

Sun, 2 Jan 2011 03:13:16 +0000

The (deep)copy function of the entity manager is not yet implemented. I assume this is known, but I could not find any open issue on it. This is a pretty powerfull feature once implemented. The function body is completely empty however. Perhaps the tried code could be added so I and others could try and resolve the known issue with this function (recursion limit reached).

[DDC-900] Insufficient Error Information for orm:validate-schema

Mon, 29 Nov 2010 06:37:16 +0000

Running "doctrine orm:validate-schema" would return -> [Database] FAIL - The database schema is not in sync with the current mapping file.

It should have at least return the name of the table/field that is not in sync.

[DDC-891] DDC-117: No sequence generation with composite foreign key

Thu, 25 Nov 2010 06:05:05 +0000

Given the following entity definitions, Doctrine does not attempt to manage generated values. For example, in MySQL, it is perfectly possible to create a composite primary key and set auto_increment on one of these. See below the code for issues that occur.

User.php

/**
 * @Entity
 */
class User {
	/**
	 * @Id
	 * @Column(type="integer")
	 * @GeneratedValue(strategy="AUTO")
	 */
	private $id;
	
	/**
	 * @Column(type="string")
	 */
	private $name;
	
	/**
	 * @OneToMany(targetEntity="PhoneNumber",mappedBy="id",cascade={"all"})
	 */
	private $phoneNumbers;
	
	public function setName ($name) {
		$this->name = $name;
	}
}

PhoneNumber.php

/**
 * @Entity
 */
class PhoneNumber {
	/**
	 * @Id
	 * @Column(type="integer")
	 * @GeneratedValue(strategy="AUTO")
	 */
	private $id;
	
	/**
	 * @Id
	 * @ManyToOne(targetEntity="User",cascade={"all"})
	 */
	private $user;
	
	/**
	 * @Column(type="string")
	 */
	private $phonenumber;
	
	public function setUser (User $user) {
		$this->user = $user;
	}
	
	public function setPhoneNumber ($phoneNumber) {
		$this->phonenumber = $phoneNumber;
	}
}

Invokation

$albert = new User;
$albert->setName("albert");
$em->persist($albert);

$phoneAlbert1 = new PhoneNumber();
$phoneAlbert1->setUser($albert);
$phoneAlbert1->setPhoneNumber("albert home: 012345");
$em->persist($phoneAlbert1);

The first issue which occurs is that Doctrine does not generate the field "id" within PhoneNumber set to auto_increment.

The second issue which occurs is that Doctrine becomes confused when inserting a new record into PhoneNumber, because of the following INSERT INTO statement:

Insert Statement

INSERT INTO PhoneNumber (user_id, phonenumber) VALUES (?, ?)
array(1) {
  [1]=>
  string(19) "albert home: 012345"
}

SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens

[DDC-17] Ability to skip the operation from a pre-operation event handler

Thu, 26 Aug 2010 08:03:54 +0000

In Doctrine 1.1 it is possible to skip the operation in the event handlers in Doctrine_Record_Listener using Doctrine_Event::skipOperation.

This no longer seems to be possible in Doctrine 2.0 Alpha 1, for example when handling a preRemove event to implement soft-delete behaviour. Perhaps a method could be added to \Doctrine\Common\EventArgs\LifecycleEventArgs to skip the operation, at least before the operation.

Without this implementing soft-delete would require the user to update deleted_at and deleted_by himself and then save the record. It could no longer be done automatically when removing a record because the record is then removed.

[DDC-547] Consider allowing custom PersistentCollection implementations

Fri, 24 Dec 2010 05:10:38 +0000

We should consider allowing the configuration of custom PersistentCollection implementations on a per-association basis.
This could allow users to craft optimized (SQL) behavior for for some of their collections to improve performance without changing the domain model code.

For this, PersistentCollection needs to be designed for inheritance.

[DDC-530] Create tests and documentation for possibilities of mixing inheritance mapping strategies

Mon, 19 Apr 2010 05:37:55 +0000

It is (theoretically) possible to use different inheritance mapping strategies in the same class hierarchy as long as the different subtrees that use different mapping strategies do not have a common ancestor entity. We should add some tests for that and mention it in the docs about inheritance mapping in a new subsection "Mixing Inheritance Mapping Strategies".

[DDC-450] Add TableGenerator Implementation

Dependency — Mon, 13 Feb 2012 14:11:35 +0000

The TableGenerator Id Generator is not yet implemented, here is some code i came up with:

class TableGenerator extends AbstractIdGenerator
{
    private $_tableName;
    private $_sequenceName;
    private $_allocationSize;
    private $_nextValue;
    private $_maxValue;

    public function __construct($tableName, $sequenceName = 'default', $allocationSize = 10)
    {
        $this->_tableName = $tableName;
        $this->_sequenceName = $sequenceName;
        $this->_allocationSize = $allocationSize;
    }

    public function generate(EntityManager $em, $entity)
    {
        if ($this->_maxValue === null || $this->_nextValue == $this->_maxValue) {
            // Allocate new values
            $conn = $em->getConnection();
            if ($conn->getTransactionNestingLevel() == 0) {

                // use select for update
                $sql = $conn->getDatabasePlatform()->getTableHiLoCurrentValSql($this->_tableName, $this->_sequenceName);
                $currentLevel = $conn->fetchColumn($sql);
                if ($currentLevel != null) {
                    $this->_nextValue = $currentLevel;
                    $this->_maxValue = $this->_nextValue + $this->_allocationSize;

                    $updateSql = $conn->getDatabasePlatform()->getTableHiLoUpdateNextValSql(
                        $this->_tableName, $this->_sequenceName, $this->_allocationSize
                    );
                    
                    if ($conn->executeUpdate($updateSql, array(1 => $currentLevel, 2 => $currentLevel+1)) !== 1) {
                        // no affected rows, concurrency issue, throw exception
                    }
                } else {
                    // no current level returned, TableGenerator seems to be broken, throw exception
                }
            } else {
                // only table locks help here, implement this or throw exception?
                // or do we want to work with table locks exclusively?
            }
        }
        return $this->_nextValue++;
    }
}

[DDC-445] Evaluate possible ways in which stored procedures can be used

Reference — Fri, 24 Dec 2010 04:49:52 +0000

We should evaluate the current situation of stored procedure support as well as where we want to go with it / how far we want to support it, if at all.

[DDC-415] Introduce UnitOfWork Stages and throw exceptions for wrong method uses

Thu, 18 Mar 2010 07:47:17 +0000

Currently the event architecture is fragile when used wrong. I already see lots of "bug reports" popping up on this issue due to people dont understanding what is doable and what is not.

How about we introduce an instance variable stage into the UnitOfWork and introduce an assertIsInStages($stages) protected method which is called ineach major command method of the UnitOfWork to verify its applied correctly?

Stages could be:

UNFLUSHED
PRE_COMPUTE_CHANGESETS
POST_COMPUTE_CHANGESETS
FLUSH_LOOP
TRANSACTION_COMPLETED

[DDC-280] UnitOfWork changeSet population should take advantage of Comparable technique

Fri, 4 Feb 2011 05:19:46 +0000

Currently our UnitOfWork computes the changeset by checking actual instances of Objects.

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml

// UnitOfWork, lines 501-507 

            foreach ($actualData as $propName => $actualValue) { 
                $orgValue = isset($originalData[$propName]) ? $originalData[$propName] : null; 
                if (is_object($orgValue) && $orgValue !== $actualValue) { 
                    $changeSet[$propName] = array($orgValue, $actualValue); 
                } else if ($orgValue != $actualValue || ($orgValue === null ^ $actualValue === null))  
	                    $changeSet[$propName] = array($orgValue, $actualValue);
                }

While this is ok when you do new object assignments, it just bypass same instances of same object, since the hash is the same.
A user on IRC (post-o-matic) has a quite complex object logic that he would like to avoid clone and even instantiate another class.
I agree with him that cloning is not the ideal technique, mainly because the changeset would always compute the object (since then hashs would be different).

He implemented this datatype:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml

class EffortGraphType extends Type 
{ 
    public function getSqlDeclaration(array $fieldDeclaration, AbstractPlatform $platform) 
    { 
        return $platform->getClobTypeDeclarationSql($fieldDeclaration); 
    } 

    public function convertToPHPValue($value, AbstractPlatform $platform) 
    { 
        return new EffortGraph(unserialize($value)); 
    } 

    public function convertToDatabaseValue($value, AbstractPlatform $platform) 
    { 
        return serialize($value->getGraphPoints()); 
    } 

    public function getName() 
    { 
        return 'effort_graph'; 
    } 
}

I was thinking in a possible alternative and it came up to me the same basic idea we have with operators overloading OR Comparable interface of Java. I know in Java it supports way more things, but at least for this situation (as a start point) it would make developer's life easier.

Basic idea is to have an interface in Doctrine\Common:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml

namespace Doctrine\Common;

interface Comparable
{
    public function compareTo($value);
}

And update our UnitOfWork to take advantage of it:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml

// UnitOfWork, lines 501-507 

            foreach ($actualData as $propName => $actualValue) { 
                $orgValue = isset($originalData[$propName]) ? $originalData[$propName] : null; 

                if (is_object($orgValue)) { 
                    $isDiff = ($orgValue instanceof Doctrine\Common\Comparable) 
                        ? $orgValue->compareTo($actualValue) :  ($orgValue !== $actualValue);

                    if ($isDiff) {
                        $changeSet[$propName] = array($orgValue, $actualValue); 
                    }
                } else if ($orgValue != $actualValue || ($orgValue === null ^ $actualValue === null))  
	                    $changeSet[$propName] = array($orgValue, $actualValue);
                }

In this user's usecase, it'd require him to update the EffortGraph class and implement Comparable interface.
For his specific situation, he'd need to store original value and updated value, just like we do internally in UnitOfWork for Entities.

[DDC-718] Bottleneck in computeAssociationChanges()?

Reference — Sat, 24 Jul 2010 04:52:23 +0000

It seems that since ~~DDC-600~~ computeAssociationChanges() iterate over entries of an collections, even if they are not marked as cascadePersist. For large, hydrated collections this could potentially become a bottleneck.

Wouldn't it be better to save the "addedEntities" in an additional map inside "PersistentCollection" and retrieve those instead of calling $value->unwrap() ?

[DDC-712] allow RIGHT JOIN or specifying the root class of the hydratation tree

Thu, 22 Jul 2010 12:21:11 +0000

Hi! Let me start by saying you guys did a great job with Doctrine 1 and that I can't wait to start using Doctrine2

I will explain this feature request with an example. I have a User entity wich relates one to many to a Picture entity. Picture has a " is main picture" boolean field. Not all users have a main picture. I would like to be able to select all Users, each with their main picutre, if that exists, or some Null value, if it does not exists, in one query, using join. I would also like for the result collection to contain Picture entities on the first level, with the User beinng accessible as an aggregate of Picture.

The way I can think doing this is by using a RIGHT or LEFT join (not INNER) as to also select Users that don't have a main picture. I can do this by selecting

SELECT Picture p, p.User u FROM p RIGHT JOIN u WITH p.main=1

but right joins afik are not available atm in either version of Doctrine, or by selecting

SELECT User u, u.Picture p FROM u LEFT JOIN p WITH p.main=1

and somehow instructing the hydrator to consider Picture as the root object for the generated object tree and User as a "child" of Picture.

For users without a picture, the Picture object would somehow indicate it is NULL, while still holding a refference to the User.

Makes sense? If there is an alternate way to achieve this, please enlighten me, tough I think it would still add felxibility if we could hint the hydrator for the root object in a tree.

[DDC-677] Allow DQL DELETE statements to work with join table fk constraints

Reference — Sat, 10 Jul 2010 08:11:06 +0000

Currently DQL DELETE will break if any foreign key constraint restricts the delete.

Using the Metadata we can possibly detect these join table FK contstraints and delete them correctly.

[DDC-4] Implement support for Concrete Table Inheritance

Fri, 24 Dec 2010 04:48:20 +0000

A first implementation could probably live without support for polymorphic queries (requires SQL UNIONs to be generated).

[DDC-747] Add support for table, column and indexes comments

Sat, 14 Aug 2010 06:32:08 +0000

It would be nice to add support for table comments, column comments and indexes comments, i.e.

@Table(
    name="ecommerce_products",
    comment="Contains products",
    indexes={@index(name="search_idx", comment="Makes finding people by name easier", columns={"name", "email"})}
)

@Column(type="integer", comment="Stores the user's age, in years")

MySQL supports comments via ALTER TABLE since 4.1.
PostgreSQL support comments via COMMENT at least since 7.4.
SQLite doesn't appear to support table, column or indexes comments as of 3.7.
Oracle supports comments on tables and columns via COMMENT at least since 10.1. It doesn't appear to support comments on indexes.

For databases that don't support those persistent comments, you could use normal SQL comments in the table definition. Of course they wouldn't be stored by the database, but at least they would appear in the generated schema, that's better than nothing.

[DDC-691] doctrine.readOnly query hint

Thu, 31 May 2012 08:16:43 +0000

Setting such a query hint to TRUE should result in all entities being retrieved by that query to be read-only for the purposes of change-tracking. Note that the entities themselves need not necessarily be read-only in general.

This feature is a flush performance tweak that can be used to query for objects but not let the returned objects run through change-tracking on flush. Any other managed objects are tracked as usual so you can do a read-only query for 100 entities and persist a new entity in the same unit of work with optimal flushing performance.

[DDC-823] Errors in 2.0 Cookbook Documentation

Mon, 11 Jul 2011 17:38:41 +0000

http://www.doctrine-project.org/projects/orm/2.0/docs/cookbook/getting-started-xml-edition/en#getting-started-xml-edition

Paragraph 1:
The benefit of Doctrine for the programmer is the possibility ~~can~~ to focus ~~soley~~ solely on the business and worry about persistence only as a secondary task. This doesn't mean persistence is not important to Doctrine 2, however it is our belief that there are considerable benefits for object-oriented programming, if persistence and entities are kept perfectly ~~seperated~~ separated.

Paragraph 2:
Entities are ~~leightweight~~ lightweight PHP Objects that don't need to extend any abstract base class or interface. An entity class must not be final or contain final methods. Additionally it must not implement __clone nor __wakeup or it should do so safely.

What would be the best way to note other errors?

[DDC-940] Entities can / can not have private properties

Wed, 15 Dec 2010 13:53:15 +0000

In the note in
http://www.doctrine-project.org/docs/orm/2.0/en/reference/working-with-objects.html#merging-entities
It appears to state that private variables are not serialized for child objects

If this is the only reason entities can't have private properties, then this restriction is no longer valid, or possibly be reconsidered.

<?php

class A {
    private $a = null;

    public function setValue($value) {
        $this->a = $value;
    }
}

class B extends A {}

$b = new B();
$b->setValue("B");
var_dump($b);

$c = unserialize(serialize($b));
var_dump($c);

The output suggests private variables are serialized, and are restored fine

[DDC-605] Include Fowards Compatible Support for Scalar Type Hints Patch in ProxyFactory

Sun, 8 Aug 2010 09:20:23 +0000

ProxyFactory needs foward compatible support for the scalar type hint patch:

http://ilia.ws/archives/217-Scalar-Type-Hints-are-Here!.html

[DDC-567] Foreign Key to Unique Field Update Failure

Mon, 8 Oct 2012 14:56:08 +0000

I am getting an error: 'Notice: Undefined index: sysname in ./libraries/Doctrine/ORM/Persisters/BasicEntityPersister.php on line 434' when I try to flush a change to a property that references a unique field on another object.

From poking around in the _prepareUpdateData function, it seems that it only allows you to use identifier fields:

$newValId = $uow->getEntityIdentifier($newVal);

..

$result[$owningTable][$sourceColumn] = $newValId[$targetClass->fieldNames[$targetColumn]];

I'll see if I can get a test case for this set up.