see http://docs.doctrine-project.org/en/latest/reference/events.html#entity-listeners

as discussed in https://github.com/doctrine/phpcr-odm/pull/268 we should implement UnitOfWork::isScheduledDocument and isScheduledFor* other than isScheduledForInsert.

Allow the query builder expression to specify an object as a target.

$qb->where($qb->expr()->eq('someObjectReference', $someObject);

So if the target passed is mapped and it is referenceable then replace the object instance with its UUID.

Parameter binding is not currently implemented in the QueryBuilder, and the comments seem to indicate that this is because jackalope does not support it at the moment.

Implement the Query->iterate method which will return an IteratableResultSet as per the ORM.

As with the ORM query object, implement the ->clone() method.

https://github.com/doctrine/doctrine2/pull/206

this is a follow-up of
https://github.com/doctrine/phpcr-odm/pull/116

i think a user might need to attach his own strategy to the document manager. we could call this path_relative= and provide "max" that string-compares the target path and the node path and puts as few ../ as necessary. but again this does not block this pull request.

http://www.doctrine-project.org/docs/orm/2.2/en/reference/change-tracking-policies.html

It will be great to be able to store array as a json in a property. There is no way to define custom mapping type (it is possible with doctrine ORM)

right now we have hardcoded \PHPCR\Util\UUIDHelper::generateUUID(), but that is a very simplistic implementation and the spec is much broader ..

when i have existing content and later change the document class to have referenceable=true, this is not updated even on persisting the document again.

uwe: I think there are several other things that fail when you have existing content in the repository - maybe the solution to think about is something like migrations ... that would prevent the performance penalty on ordinary code and still give you the change to change the structure of your documents.

things that come to mind

• change document class name
• removing fields
• change field type
• bulk changing the values in some field
• everything related to node types (though, as an additional challenge at least jackrabbit does not allow to remove things from node types through the davex remoting we use in jackalope)

see also http://www.doctrine-project.org/docs/mongodb_odm/1.0/en/reference/logging.html

https://doctrine-mongodb-odm.readthedocs.org/en/latest/reference/migrating-schemas.html