Skip to end of metadata
Go to start of metadata

<p>ZF2 will at some areas offer integration with Doctrine2. There are however no plans to ship Doctrine2 with ZF itself. Even if we would want to ship Doctrine2, it would be impossible because of contradicting licenses.</p>

<p>When talking about integration, you can think of:</p>
<li>A ResourcePlugin for Zend\Application that bootstraps Doctrine</li>
<li>An adapter for Zend\Authentication that relies on Doctrine</li>
<li>A cache driver implements Doctrine\Common\Cache\Cache using Zend\Cache</li>
<li>A Zend\Navigation adapter that uses Doctrine.</li>
<li>A writer for Zend\Log</li>
<li>A Doctrine-adapter that can be utilized by Zend\Paginator</li>
<li>A Doctrine-adapter that can be utilized by Zend\Queue</li>
<li>A Doctrine-version of Zend\Validator\Db</li>
<li>A Doctrine-provider that can be utilized by Zend\Tool</li>

<p>Note: Since ZF2 is all new and cool and stuff, we forget about Doctrine version 1...</p>

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jan 12, 2011

    <p>An adapter for Zend\Paginator ?</p>

    1. Jan 12, 2011

      <p>If anyone steps up to write that we'll be likely to have that too. Adding to the page.</p>

      1. Jan 13, 2011

        <p>We already have one created for ZF 1.x, all we would need to do is update it for Doctrine 2.x and make a ZF 2.x version. Should be a rather quick change.</p>

        1. Jan 14, 2011

          <p>Paginator for ZF1 and Doctrine 2 already exists. You can find it here <a class="external-link" href=""></a> </p>

          <p>The problem is that to have support for pagination inside Doctrine 2 you need to use an extension. And I believe that the extension will be shipped with a ZF2 Paginator adapter once the ZF2 gets some traction. </p>

          1. Sep 19, 2011


            <p>It's working perfect with Doctrine 2.0</p>

  2. Jan 15, 2011

    <p>An cache driver implements Doctrine\Common\Cache\Cache using Zend\Cache</p>

  3. Jan 22, 2011

    <p>I would also like to suggest Zend_Session_SaveHandler_Doctrine. Given Doctrine's DBAL, one could choose to save to Mongo or Redis as an alternative to something like memcache.</p>

  4. Jan 30, 2011

    <p>I suggest an ACL Doctrine-provider for Zend\Access if the feature provider exists.</p>

  5. Mar 01, 2011

    <p>It would be nice to use Zend\Form with entities also with Zend validators. Like in Symfony: <a class="external-link" href=""></a></p>

    <p>I think validation should be in model level and forms have to use these validators (plus some optional validators). I started a project here: <a class="external-link" href=""></a><br />
    Probably I will modify the existing code because it could be better...</p>

    <p>Sorry for my bad english.</p>

  6. Mar 15, 2011

    <p>For me one of the most wanted features, beside the Zend_Application resource plugin, is the tighter connection between Zend_Tool and the Doctrine cli commands. A Zend_Tool manifest with commands which proxy to Doctrine_Cli (or another method) might become very useful. Especially when in ZF2 more attention is paid to Zend_Tool and its features.</p>

  7. Oct 23, 2011

    <p>Regarding the list of integration points above:</p>

    <li><strong>Zend\Application</strong>: Bootstrap resources have been replaced with Zend\Di. Support could be provided through a set of factory classes for use with Zend\Di, which can then pass the entity manager instances to any classes that need them. Keeping this in the DI layer, rather than a container class, would allow for switching out an entity manager without changing any other code.</li>
    <li><strong>Zend\Authentication</strong>: The ZF1 style database adapter could be re-created with findOneBy(), using the Entity name instead of directly specifying the database table/column.</li>
    <li><strong>Zend\Validator\Db</strong>: Same as Zend\Authentication.</li>
    <li><strong>Zend\Cache</strong>: The Doctrine Cache implements a subset of Zend\Cache, a proxy class could be a good choice here.</li>
    <li><strong>Zend\Navigation</strong>: Uncertain, see below.</li>
    <li><strong>Zend\Log</strong>: An ORM or DBAL version of this class would be simple to build. Making it work with any other storage backend (MongoDB, CouchDB, etc) may take specific adapters.</li>
    <li><strong>Zend\Paginator</strong>: Already discussed in other comments.</li>
    <li><strong>Zend\Queue</strong>: Don't know enough about Zend_Queue.</li>
    <li><strong>Zend\Tool</strong>: Don't know enough about Zend\Tool. Perhaps a simple bootstrapping harness that wraps the Doctrine's own CLI tools.</li>

    <p>Rather than building ORM specific implementations, it might be better to code against the Doctrine\Common\Persistence interfaces, creating one version for MySQL, MongoDB, Couch, etc. There's enough functionality there to implement most components. </p>

    <p>For others that might take more specific query functions (Zend\Navigation, for example), we might still need specific ORM or MongoDB adapters. There should be a clear class hierarchy to make it clear which adapters are specific to a backend and those which are common. </p>

    <p>Some of the components like Navigation and ACL might benefit from a hierarchy technique such as NestedSet or MP but it's not core in either project and shipping a third party one might be tricky. For others, like Paginator, there are existing classes; if we can find one with the correct licensing, it would save some work.</p>

    <p>I'd love to see more done with using the ClassMetadata, such as automatically building validator chains or populating form options through relations but this should probably be a separate RFC.</p>