When executing

$query = $em->createQuery(
'SELECT m.nombre, m.fechainicio, m.fechafin FROM Bundle:Medicion m
JOIN m.estudio e
JOIN e.cliente c
JOIN c.usuarios u
WHERE u.id = :id
ORDER BY m.fechainicio DESC')
->setMaxResults(12)
>setParameter('id', $user>getId());

Get the following error:

An exception occurred while executing 'SELECT * FROM (SELECT m0_.NOMBRE AS NOMBRE0, m0_.FECHAINICIO AS FECHAINICIO1, m0_.FECHAFIN AS FECHAFIN2, ROW_NUMBER() OVER (ORDER BY FECHAINICIO1 DESC) AS doctrine_rownum FROM MEDICION m0_ WITH (NOLOCK) INNER JOIN ESTUDIO e1_ ON m0_.ESTUDIO_ID = e1_.ID INNER JOIN CLIENTE c2_ ON e1_.CLIENTE_ID = c2_.ID INNER JOIN USUARIO u3_ ON c2_.ID = u3_.CLIENTE_ID WHERE u3_.ID = ?) AS doctrine_tbl WHERE doctrine_rownum BETWEEN 1 AND 12' with params [2]:

SQLSTATE[42S22]: [Microsoft][SQL Server Native Client 11.0][SQL Server]El nombre de columna 'FECHAINICIO1' no es válido.

Attached the BD model

regards
Jonnatan Oyarzún

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.

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))

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

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?

@ManyToOne and @OneToOne on mapped superclasses have to be unidirectional. The Schema Validator should verify this.

More information coming soon. Attaching a test case

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.

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.

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

In the QueryBuilder section of the documentation (http://www.doctrine-project.org/docs/orm/2.1/en/reference/query-builder.html#the-expr-class) there's an example with statements like

 
$qb->expr()->select('u')

But this doesn't work anymore.

We have association on non primary key. Something like this:

Entities\Payment:
  type: entity
  table: payments
  fields:
    id: 
      id: true
      type: integer
      nullable: false
      generator:
        strategy: IDENTITY
[-- skipped --]
  manyToOne:
    order:
      targetEntity: Entities\Order
      inversedBy: payments
      joinColumn:
        name: scode
        referencedColumnName: scode

Entities\Order:
  type: entity
  table: h_orders
  fields:
    id:
      id: true
      type: integer
      unsigned: false
      nullable: false
      generator:
        strategy: IDENTITY
    scode:
      type: integer
      unsigned: false
      nullable: false
[-- skipped --]
  oneToMany:
    payments:
      targetEntity: Entities\Payment
      mappedBy: order

When I try to fetch Order from Payment with lazy loading I receive empty Order object with null properties. If I use eager fetching Order object is valid.
SQL generated for lazy loading seems to be valid, so I suppose the problem is in mapping result to the object. At the same time lazy loading works fine with 2.0.6 version.

Another problem appears while persisting new Payment.

$payment = new \Entities\Payment();
...
$order = $this->em->getRepository('\Entities\Order')->find(46320);
$payment->setOrder($order);
$order->addPayments($payment);
$this->em->persist($payment);
$this->em->flush();

I get this error: Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'scode' cannot be null' in /usr/share/php/Doctrine/DBAL/Statement.php:131

I found issue which is still open and looks like mine – http://www.doctrine-project.org/jira/browse/DDC-1114. What do you think about this?

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.

Could it be possible to allow for arbitrary many to one entities through a "class + id" construct as join columns?

Or maybe some template-files could be provided for all stubs.

private static $_setMethodTemplate =
'/**
 * <description>
 *
 * @param <variableType>$<variableName>
 */
public function <methodName>(<methodTypeHint>$<variableName>)
{
<spaces>$this-><fieldName> = $<variableName>;

<spaces>return $this;</spaces>
}';

according to Stof, this bug https://github.com/sensio/SensioGeneratorBundle/issues/21 comes from the doctrine tools implementation:

in the dialog, i first specified that i want a field id of type integer. the result was

[Doctrine\ORM\Mapping\MappingException]

Duplicate definition of column 'id' on entity 'Liip\DemoBundle\Entity\Event' in a field or discriminator column mapping.

and no file was created.

The dialog should tell me i can not create a field named id. (Or better ask first if i want my id column named id or something else.)

It would be nice if it would write some file even if its not valid, with a warning on top. As it is, i lost all my work of specifying fields. (Luckily was just playing around)

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"?

DBAL provides a ReservedKeywordsValidator to check whether a word is reserved. But this tool is not used by the ORM when validating the schema. It would be useful to use it to avoid WTF from users getting a PDOException when creating their schema because of this.
The other solution if you don't want to add this in orm:validate-schema would be to create a dedicated command.

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.

DQL Example about count related entity is wrong

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. "

If you subscribe to loadClassMetadata you will usually modify the metadata for some classes.
The problem is, that that data has to be loaded from somewhere. But later down the chain you can't get to it. Now data specific to what you need in your loadClassMetadata would ideally reside in the same location.
If we take for example a file, than all data for a specific entity is in the same file.

My proposal would be to add function get(Original|Raw)MappingData into interface Doctrine\ORM\Mapping\Driver\Driver which would either return raw data or data in a object specific for that Driver or null if it doesn't make sense for that driver. Please note, that when loading from e.g XmlDriver we should return simplexmlnode or dom node as loadClassMetadata should be in its own namespace and not pollute the Doctrine one.

Doctrine:schema:update --force is the same as doctrine:schema:create.

Under the hood, this may not be true, but they basically accomplish the same task. Schema:create should be removed, as it is redundant.

Just look at django, one command to update db:

./manage.py syncdb

Not saying that django gets everything correct, but the one command to synchronize the database is consistent. doctrine:schema:update should be smart enough to do all of the work, instead of relying on the redundant doctrine:schema:create.

Read the IRC log:

[2:38pm] guilhermeblanco: beberlei: ping
[2:38pm] guilhermeblanco: I'm curious about a feature if Doctrine supports
[2:38pm] guilhermeblanco: if we do this on a proxy:
[2:38pm] guilhermeblanco: $proxy->getOneToOneAssoc()
[2:39pm] guilhermeblanco: shouldn't Doctrine already populate the assoc entity?
[2:39pm] guilhermeblanco: it would be an inner join
[2:39pm] beberlei: how would doctrine know it needs it?
[2:39pm] guilhermeblanco: beberlei: it always repass the ClassMetadata to Persister
[2:40pm] guilhermeblanco: so all needed item is to also pass the fieldname/assocname
[2:40pm] beberlei: but how would doctrine know getOneToOneASsoc() really returns this assoc
[2:40pm] beberlei: it could contain any logic
[2:40pm] guilhermeblanco: it wouldn't... but as soon as we trigger __load($fieldName)
[2:40pm] guilhermeblanco: we know that we could populate not only the Proxy, but also assoc
[2:40pm] beberlei: by convention?
[2:40pm] guilhermeblanco: ya
[2:41pm] beberlei: sounds good, can you open a ticket?
[2:41pm] guilhermeblanco: getUser() would trigger __load('user')
[2:41pm] guilhermeblanco: sure!
[2:41pm] guilhermeblanco: I'll pastie this as content... it would be awesome to have
[2:41pm] guilhermeblanco: I see a lot of queries here that could be optimized 

http://www.doctrine-project.org/docs/orm/2.0/en/reference/caching.html
mentions $cacheDriver->setManageCacheIds(true);.
But method absent from V 2.04, possibly just needs a version note next to it.

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.

a quick search through the ORM code base finds quite a few tabs. other doctrine projects there might also be some, though in common i only found some inside the LGPL license file.

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

To find out if a model is persist, is missing in the documentation of doctrine 2.

To become the state of an model you must call the entitymanager->getUnitOfWork()->getEntityState(model)

On http://www.doctrine-project.org/docs/orm/2.0/en/reference/dql-doctrine-query-language.html#adding-your-own-functions-to-the-dql-language the code example is slightly incorrect.

Mistakes:

• Lexer::T_ABS doesn't exist anymore, I assume Lexer::T_IDENTIFIER is what one wants to use
• Missing use for \Doctrine\ORM\Query\Lexer

Additionally, the section should tell the user that he best has a look at lib/Doctrine/ORM/Query/AST/Functions/* to learn how to write custom functions. It also could be noted that stored procedures can be called with custom functions.

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");
}

If you need to override the ID Generator, e.g. during a migration, you can do that in your migration script as follows:

Make sure that both calls equal to the same generator type. You can now modify the @Id fields in your entities. Additionally, make sure that you set the IdGenerator after you created the database using e.g. SchemaTool->create().

We can not set MySql Engine for MyISAM. MySqlPlatform has a _getCreateTableSQL where you can pass some options with the engine param.
Not able to set it up from yml, xml or annotation schema.

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

http://www.doctrine-project.org/docs/dbal/2.0/en/reference/types.html links to http://www.doctrine-project.org/docs/dbal/2.0/en/known-vendor-issues instead of http://www.doctrine-project.org/docs/dbal/2.0/en/reference/known-vendor-issues.html

Also noticed that the documentation still says "Doctrine DBAL v2.0.0-BETA4 documentation"

We should optimize code-generation somehow.

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

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?

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

Our current code-generation tool has many shortcomings and due to its hard to test nature also many (known and unknown) bugs, as well as high maintenance.

Since people are overusing this tool and I am sort of annoyed by how much time goes into this we should rewrite this in a two-step procedure:

1. Move code into Common so we can share it between ORM, Mongo and CouchDB.
2. Use PDepend to read an entities source file (it generates an AST) and modify the AST with the required changes.

This gives us the advantage of having to maintaining less code for this stuff.

Pull-Request was automatically synchronized: https://github.com/doctrine/doctrine2/pull/162

Wheeee, nested proxies can be generated without hassle!

When you are looking for a config example for the bidirectional mapping of an one-to-many association you will just find an example with XML, but not with YAML or PHP. It would be nice if somebody could add an example or a link to the bidirectional one-to-one association, because it should be the same, right?

Here the link to the example: http://www.doctrine-project.org/docs/orm/2.0/en/reference/association-mapping.html#one-to-many-bidirectional

Using the DQL "partial" keyword is not enough to get a partial entity as a result.
The DQL hint HINT_FORCE_PARTIAL_LOAD must be used as well.

$q = $em->createQuery('SELECT partial r.{id,comment} FROM Entities\Rating r WHERE r.id=3');
$r = $q->getResult() /* HYDRATE_OBJECT is the default hydration mode */

Here, $r contains the full Entity, a SELECT * has been sent

$q = $em->createQuery('SELECT partial r.{id,comment} FROM Entities\Rating r WHERE r.id=3');
$q->setHint(Doctrine\ORM\Query::HINT_FORCE_PARTIAL_LOAD, 1);

$r = $q->getResult() /* HYDRATE_OBJECT is the default hydration mode */

Here, $r contains only the selected fields, hence a true partial Entity

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.

Error messages throughout ClassMetadata validation and UnitOfWork cycles can be significantly improved.

Work is being done on: https://github.com/doctrine/doctrine2/tree/ImproveErrorMessages

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.

Add test for DDC-1437

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?

There should be a sane way to skip sources of errors in SchemaTool and the DatabaseDriver.

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

We can implement optimistic locking using hash values or other all columns of an entity