RFC - Doctrine2

An adapter for Zend\Paginator ?

An cache driver implements Doctrine\Common\Cache\Cache using Zend\Cache

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.

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

It would be nice to use Zend\Form with entities also with Zend validators. Like in Symfony: http://docs.symfony-reloaded.org/guides/forms/overview.html#forms-and-domain-objects

I think validation should be in model level and forms have to use these validators (plus some optional validators). I started a project here: https://github.com/szjani/equcms
Probably I will modify the existing code because it could be better...

Sorry for my bad english.

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.

Regarding the list of integration points above:

• Zend\Application: 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.
• Zend\Authentication: The ZF1 style database adapter could be re-created with findOneBy(), using the Entity name instead of directly specifying the database table/column.
• Zend\Validator\Db: Same as Zend\Authentication.
• Zend\Cache: The Doctrine Cache implements a subset of Zend\Cache, a proxy class could be a good choice here.
• Zend\Navigation: Uncertain, see below.
• Zend\Log: 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.
• Zend\Paginator: Already discussed in other comments.
• Zend\Queue: Don't know enough about Zend_Queue.
• Zend\Tool: Don't know enough about Zend\Tool. Perhaps a simple bootstrapping harness that wraps the Doctrine's own CLI tools.

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.

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.

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.

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.