clean up the event argument classes to only use specific classes if needed, and base on doctrine commons events

see https://github.com/doctrine/phpcr-odm/pull/246 and https://github.com/doctrine/phpcr-odm/issues/245

changes to the @ParentDocument and @Name should be translated to move operations. they are the most natural way to move a document in a form.

creating and removing references

when loading a node from the database, you can either explicitly specify the document class to be used or it is determined programmatically. you can inject your own logic, but the default logic is right in UnitOfWork, and duplicated. this should be moved to a separate class for better reusability.

this would also be a good moment to get rid of phpcr:alias in favor of phpcr:class. we could provide an implementation for the old phpcr:alias as one of the resolvers users can plug in, if somebody really prefers the alias approach.

see https://github.com/doctrine/doctrine2/pull/166

see http://groups.google.com/group/symfony-cmf-devs/browse_thread/thread/914ba1c32d873ed5

This issue is created automatically through a Github pull request on behalf of

:

Url: https://github.com/doctrine/phpcr-odm/pull/59

Message:

first of all: sry, i screwed up the commit history here again

Well this is support for referrers.
This patch provides the new annotation "Referrers".
By default a property of this type stores all referrers (weak and hard) in a collection.
You can specify the option "referenceType" with the values "weak" and "hard" (or null) to only get the one or the other type of referring documents (or both types)
Then there is the option "filterName". It's value is passed to the method "get(Weak)References". Actually the option passed to "get(Weak)References" is called "name" in the spec. I named it "filterName" here as "name" is already assigned.

This issue is created automatically through a Github pull request on behalf of

:

Url: https://github.com/doctrine/phpcr-odm/pull/56

Message:

The wrapped metadata driver ensures that metadata for the builtin
documents is loaded. Still the DoctrineAnnotations need to be registered
with the AnnotationRegistry.

see https://github.com/symfony-cmf/cmf-sandbox/issues/20

I just noticed that we have an issue in our metadata loading in case a document name is prefixed with a backslash when calling find

// fails
$dm->find('\Foo\Bar', $path);

// works
$dm->find('Foo\Bar', $path);

Should the first work as well?

I have traced the issue to the DriverChain

public function loadMetadataForClass($className, ClassMetadata $class)
{
foreach ($this->drivers as $namespace => $driver) {
if (strpos($className, $namespace) === 0)

}

throw MappingException::classIsNotAValidDocument($className);
}

notice the strpos() does not bother to check if a preceding backslash is in the $className var.

PHPCR ODM is listed on the Doctrine website:
http://www.doctrine-project.org/projects/phpcr_odm

build doc in this repository:

https://github.com/doctrine/phpcr-odm-documentation

The next step would be to collect all the various documentation flying around and convert them to reST format:
https://github.com/doctrine/phpcr-odm/wiki/_pages
http://melp.nl/2011/07/symfony2-phpcr-doctrine2-jackalope-recipe/ (needs to be made Symfony2 unspecific)
http://www.craftitonline.com/2011/07/first-symfony2-cmf-based-cms-pagesbundle/ (needs to be made Symfony2 unspecific)
http://cmf.symfony.com/slides.html (needs to be made Symfony2 unspecific)

any other articles flying around?

of course we should also reference PHPCR related docs

once reference annotation in PHPCR-10 is finished, we should also map the inverse, the list of documents referencing this document. this is a read only property.

Have an id generator that can build the path (id) from parent node and node name.
(The current setup with the id being the path leaves it to the user to make sure the parent node exists. You get really non-helpful strange error message if the parent does not exist.)

make document class detection strategy injected. this is in Doctrine/ODM/PHPCR/UnitOfWork.php createDocument

the default strategy should do the current behaviour in that method, but use the explicit parameter first if specified before looking at the phpcr:class attribute.

• Create better user documentation. The README is far too long, split it.
• Create some documents for the doctrine website and do a doctrine-project.org/projects/phpcr_odm

• Annotation to map node name to a field (read-only except when creating a document). should be NodeName because NAME is one of the property types.
• Align the annotations with the PHPCR\PropertyType types and map all types (missing for example the PATH type).

The phpcr-odm should use the factory implementations to bootstrap the phpcr implementation, instead of using new Repository (and jackalope transport and whatnot)

MANY_TO_MANY referenced are now only loaded on demand (see PHPCR-52) via the ReferenceManyCollection. But MANY_TO_ONE are not yet, to be implemented

https://github.com/doctrine/phpcr-odm/pull/97#r410832

reported by nacmartin https://github.com/symfony-cmf/symfony-cmf/issues/131

Since this property was introduced

https://github.com/symfony-cmf/symfony-cmf/blob/master/src/Symfony/Cmf/Bundle/ContentBundle/Document/StaticContent.php#L44

I have this error when persisting this kind of document in SAB:

MappingException: Class Doctrine\ODM\PHPCR\ReferrersCollection is not a valid document or mapped super class.

Any clue?

=> phpcr-odm should not try to persist a ReferrersCollection. this is just the inverse of the Reference annotation. as this is directional in phpcr, the ReferrersCollection should be immutable by the client.

the targetDocument describes what class to expect in the reference. as the class is usually determined automatically, this parameter should be optional.

this is a follow-up for https://github.com/doctrine/phpcr-odm/pull/144#issuecomment-7096029

we need to check if mapped superclass is working as it should, and then clarify the doc at https://github.com/doctrine/phpcr-odm-documentation/blob/master/en/reference/inheritance-mapping.rst

i still did not understand what exactly the feature means.

managed documents can only ever exist once per DocumentManager, and thus only in one language. for this reason we did not want to make the language propagate for mapped children and references (as this would change the content of documents in a hard to understand way - and loading anything in a different language again would still lose the language)

thus we should provide a findTranslation variant to get a detached translated document that fetches all associations as detached as well, keeping the locale setting.

there is no way to handle the write case, but this would cover the read case.

i am pretty sure the DocumentManager::find() method creates a duplicate document each time you request the document by uuid. it should not just load the node but convert that node to a path and then do the check if the document is cached. if the node is already cached the lookup by uuid is cheap. if not, it is now cached and the lookup by path is cheap. so no overhead, but eliminate the risk of having several instances of the same document.

https://github.com/doctrine/phpcr-odm/blob/master/lib/Doctrine/ODM/PHPCR/DocumentManager.php#L279

https://github.com/jackalope/jackalope/pull/113

the idea would be to set the depth via a mapping on a per model or per collection basis

according to http://docs.doctrine-project.org/projects/doctrine-orm/en/2.1/reference/events.html#prepersist the persist event is only triggered when persisting a new entity/document. but currently the phpcr-odm uow triggers it during the flush operation.

we have to go over the event system and clean that up.

when replacing a mapped child with a new document, we get the cannotMoveByAssignment exception, which imo is a) the wrong message as its not about setting a tracked document to become a child somewhere else but what we should do is delete the existing child document and add the new one.

this happens at https://github.com/doctrine/phpcr-odm/blob/master/lib/Doctrine/ODM/PHPCR/UnitOfWork.php#L1912

for multiple children, i am less sure how it should work, if it is possible the same way:
https://github.com/doctrine/phpcr-odm/blob/master/lib/Doctrine/ODM/PHPCR/UnitOfWork.php#L935

currently the language fallback is defined like this

locales:
en: [en, de]
de: [de, en]

the first option must be the requested language. this is counterintuitive and error prone. saying "en: [de]" would make english always only try german. we should add the locale itself as first locale i think, i see no use case of defining fallbacks where the requested locale is not the one to be preferred.

we should have a document level mapping to declare arbitrary mixins (like mix:created and mix:lastModified to have autogenerated timestamp fields that then can be mapped)

I just tried the odm on a testproject. but i have a really strange problem with translations. if i add a document which has children - and then try to add a translation to the children documents - the translation will not be saved .... (i tried the same with the symfony cmf - same result )
code:

Currently the DocumentManager->getReferrers() method returns only referrers that have already been flushed to the database.

It is (I think) desireable for this method to return also those objects which have been added to the UnitOfWork but have not yet been flushed to the database.

Look at test coverage and write more tests if necessary. Focus on the exposed api functional tests so the changes to share code with mongo db PHPCR-19 can be tested.

we should have an annotation to have multivalue properties be hashmaps, that is arrays with custom keys that get preserved. there are 3 options:

• two multivalue fields with keys and values respectively. see i.e. https://github.com/symfony-cmf/symfony-cmf/pull/140 (another workaround can be to use the @PostLoad and @PreUpdate hooks to split/merge the arrays)
• serialize the array into a string field
• child nodes (performance penalty). they would need to be in a special namespace to be identifyable and have a special format. a node for key-value is a lot. if you want a document with a specific name, you should use child documents directly, not a hashmap with document entry.

meaning if B extends A and someone does ->find('A') that it would find instances of B
this will require changes to ClassMetadataFactory::doLoadMetadata()
https://github.com/doctrine/phpcr-odm/blob/master/lib/Doctrine/ODM/PHPCR/Mapping/ClassMetadataFactory.php#L119

right now we only really support checking the dirty state of MultivaluePropertyCollection instances. however in some cases it might be necessary to convert things to an array, even if there are no actual changes. therefore it would be good to also check the dirty state in case of an array

https://github.com/doctrine/mongodb-odm/commit/2da6e9c92d515edae7c63233740349e0d272b19b

see the ORM