Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-218

@Version column is not reflected in resultColumnNames in StandardEntityPersister, generates E_NOTICE

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-ALPHA3
    • Fix Version/s: 2.0-ALPHA4
    • Component/s: ORM
    • Security Level: All
    • Labels:
      None
    • Environment:
      Ubuntu 9.10 ("Karmic", 64bit) / Debian 5.0 ("Lenny", 64bit), PostgreSQL 8.3.8 / 8.4.1 (each 64bit), PHP 5.3.0 / 5.3.1 (64bit)

      Description

      Scenario: 2 classes with a "OneToMany" Bi-Directional Mapping

      abstract class AbstractBase
      {
      	/** 
      	 * @Id @Column(type="integer")
      	 * @GeneratedValue(strategy="AUTO")
      	 * @var integer
      	 */
      	public $id;
      	
      	/**
      	 * @Version @Column(name="version", type="integer")
      	 * @var integer
      	 */
      	public $version;
      ...
      }
      
      class Property extends AbstractBase
      {
      ...
      	/**
      	 * @todo used to have an "'orderBy' => 'order_number ASC' // default ordering for this field" back in 1.2.x
      	 * http://www.doctrine-project.org/documentation/manual/2_0/en/association-mapping#one-to-many,-bidirectional
      	 * @OneToMany(targetEntity="Webges\Core\Property\PropertyOption", mappedBy="Property")
      	 * @var \Webges\Core\Property\PropertyOption
      	 */
      	public $Options;
      }
      
      class PropertyOption extends AbstractBase
      {
      ...
      	/**
      	 * http://www.doctrine-project.org/documentation/manual/2_0/en/association-mapping#one-to-many,-bidirectional
      	 * @ManyToOne(targetEntity="Webges\Core\Property\Property")
      	 * @JoinColumn(name="property_id", referencedColumnName="id")
      	 * @var \Webges\Core\Property\Property
      	 */
      	public $Property;
      }
      

      When I load an instance of Property using DQL and lazy-load the PropertyOption objects, I get an E_NOTICE saying "Notice: Undefined index: version in Doctrine/ORM/Persisters/StandardEntityPersister.php on line 579"

      After debugging the source I noticed that the MetaClass definitionfor PropertyOption is correct - the class is marked as "isVersioned", also the "version" column is contained in the "columnNames" and "fieldNames" mapping, but not in "resultColumnNames" - this is also true for some other fields contained in AbstractBase

      Maybe this is desired behaviour and there is a fix to it which I might not see yet (clues appreciated!), but to me and my colleague this seems like a bug in the data mapping.

      1. DDC218Test.php
        3 kB
        Roman S. Borschel

        Issue Links

          Activity

          Hide
          Roman S. Borschel added a comment -

          Of course, I am testing against trunk.

          Show
          Roman S. Borschel added a comment - Of course, I am testing against trunk.
          Hide
          Roman S. Borschel added a comment -

          Also note that when you're using APC as the metadata cache during development that you may need to flush the cache in order for changes to take effect.

          During development its usually the most convenient to work without a metadata cache.

          Note on the caches: In a production environment, APC is the best choice for metadata & query cache, even if you scale horizontally across multiple servers since the metadata is not related to users (its not like session data) and is the same on each server thus each PHP server can have its own APC metadata cache, which only occupies a few MB of RAM with a few hundred mapped classes. Memcache is a good alternative but slower since it involves network overhead.

          Show
          Roman S. Borschel added a comment - Also note that when you're using APC as the metadata cache during development that you may need to flush the cache in order for changes to take effect. During development its usually the most convenient to work without a metadata cache. Note on the caches: In a production environment, APC is the best choice for metadata & query cache, even if you scale horizontally across multiple servers since the metadata is not related to users (its not like session data) and is the same on each server thus each PHP server can have its own APC metadata cache, which only occupies a few MB of RAM with a few hundred mapped classes. Memcache is a good alternative but slower since it involves network overhead.
          Hide
          Michael Zach added a comment -

          I know, also tried the ArrayCache instead of ApcCache, but this does not affect the outcome.

          Going to check your test and then modify it to reflect our current setup.

          Show
          Michael Zach added a comment - I know, also tried the ArrayCache instead of ApcCache, but this does not affect the outcome. Going to check your test and then modify it to reflect our current setup.
          Hide
          Michael Zach added a comment -

          I've re-created the scenario within the testcase and figured two things out:

          • first: version-Problem was fixed in trunk, exists in -ALPHA3
          • second: it's not necessary any more to have an whateverId column in the entity itself if an relation $whatever exists, which we had during a manual update

          So from my side this issue can be closed, just need to upgrade to /trunk.

          Thank you

          Show
          Michael Zach added a comment - I've re-created the scenario within the testcase and figured two things out: first: version-Problem was fixed in trunk, exists in -ALPHA3 second: it's not necessary any more to have an whateverId column in the entity itself if an relation $whatever exists, which we had during a manual update So from my side this issue can be closed, just need to upgrade to /trunk. Thank you
          Hide
          Roman S. Borschel added a comment -

          Ok, thanks. I mark this as fixed for ALPHA4 then.

          And your observation about the foreign keys is correct. There is no need to have foreign keys in the object model. They're details of the relational database. Your objects have object references, not foreign keys, obviously. This is an important aspect of decoupling the objects from the concrete data store where they are persisted. For example, if you later want to store the same objects in another storage like CouchDB, the foreign keys have absolutely no meaning. Sometimes, unfortunately, it is still necessary to map foreign keys into object fields currently when using some complex composite keys. But when you stay away from composite keys (except in a pure many-many association table that has no corresponding entity, in which case you get the composite key generated by doctrine anyway) then you're all fine.

          Show
          Roman S. Borschel added a comment - Ok, thanks. I mark this as fixed for ALPHA4 then. And your observation about the foreign keys is correct. There is no need to have foreign keys in the object model. They're details of the relational database. Your objects have object references, not foreign keys, obviously. This is an important aspect of decoupling the objects from the concrete data store where they are persisted. For example, if you later want to store the same objects in another storage like CouchDB, the foreign keys have absolutely no meaning. Sometimes, unfortunately, it is still necessary to map foreign keys into object fields currently when using some complex composite keys. But when you stay away from composite keys (except in a pure many-many association table that has no corresponding entity, in which case you get the composite key generated by doctrine anyway) then you're all fine.

            People

            • Assignee:
              Roman S. Borschel
              Reporter:
              Michael Zach
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: