[PHPCR-102] DocumentManager::reorder can not be called multiple times for the same parent Created: 01/Mar/13  Updated: 19/Apr/13  Resolved: 19/Apr/13

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: David Buchmann Assignee: David Buchmann
Resolution: Fixed Votes: 0
Labels: None


 Description   

unless i really misread the code in UnitOfWork::scheduleReorder, trying to reorder more than one child of the same parent document will drop the previous reordering.

the whole method is of limited use, as you can also reorder the children in the ChildrenCollection.

 Comments   
Comment by David Buchmann [ 18/Apr/13 ]

expand to have an array of reorderings per parent instead of just one reordering.

Comment by David Buchmann [ 19/Apr/13 ]

https://github.com/doctrine/phpcr-odm/pull/278




[PHPCR-11] Expose transaction API Created: 01/Jul/11  Updated: 15/Oct/11  Resolved: 15/Oct/11

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Lukas Kahwe Assignee: Jordi Boggiano
Resolution: Fixed Votes: 0
Labels: None


 Description   

this requires support in PHPCR/Jackalope

 Comments   
Comment by David Buchmann [ 22/Jul/11 ]

when you get the phpcr session, you can call getTransactionManager on it and do transactions (its pretty simple). lukas, do you think anything more is needed?

@jordi: can you give me more rights in this jira so i can assign tickets?

Comment by Lukas Kahwe [ 10/Oct/11 ]

can we close this one?




[PHPCR-8] add support for getting node(s) with subnodes at once Created: 01/Jul/11  Updated: 10/Oct/11  Resolved: 10/Oct/11

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Lukas Kahwe Assignee: Jordi Boggiano
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

this requires support for this in PHPCR/jackalope

 Comments   
Comment by Lukas Kahwe [ 19/Aug/11 ]

maybe the only way to support this reasonable is via JOIN's in queries and getSubNodes()

Comment by Lukas Kahwe [ 10/Oct/11 ]

JOINs are indeed the right approach ..




[PHPCR-5] test with Midgard2 PHPCR Created: 01/Jul/11  Updated: 28/Dec/11  Resolved: 28/Dec/11

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Lukas Kahwe Assignee: Jordi Boggiano
Resolution: Fixed Votes: 0
Labels: None


 Description   

https://github.com/bergie/phpcr-midgard2



[PHPCR-1] children/child annotation add value later Created: 23/Jun/11  Updated: 22/Jul/11  Resolved: 22/Jul/11

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: David Buchmann Assignee: Jordi Boggiano
Resolution: Fixed Votes: 0
Labels: None


 Description   

when using the child annotation, it is not possible to assign a child document with a child of its own after persisting the parent document. to reproduce, take the Functional/FileTest.php and change
$parent->file = new File();
$parent->id = '/functional/filetest';
$parent->file->setFileContentFromFilesystem(dirname(_FILE_) .'/_files/foo.txt');

$this->dm->persist($parent);

to
$parent->id = '/functional/filetest';
$this->dm->persist($parent);

$parent->file = new File();
$parent->file->setFileContentFromFilesystem(dirname(_FILE_) .'/_files/foo.txt');

you will get "mandatory child node

{http://www.jcp.org/jcr/1.0}

content does not exist"

 Comments   
Comment by David Buchmann [ 23/Jun/11 ]

probably related is the issue that updating the normal properties of a child is not stored into phpcr.

Comment by David Buchmann [ 22/Jul/11 ]

https://github.com/doctrine/phpcr-odm/pull/50




[PHPCR-2] load document with child annotation Created: 23/Jun/11  Updated: 24/Jun/11  Resolved: 24/Jun/11

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: David Buchmann Assignee: Jordi Boggiano
Resolution: Fixed Votes: 0
Labels: None


 Description   

if i did not previously load a document of the class of the child, phpcr-odm can not know the alias to load it. it throws an exception.

for example, use $this->documentManager->find('My\Class', '/path/to/document'); where My\Class has an @child annotation for a child that is a File. it has the file alias, but phpcr-odm knows nothing of that alias if i did not previously try to find something with 'Doctrine\...\File' that made it load the meta data.

the workaround is to get the repositories to make phpcr-odm know the alias, but this is no solution.
$this->documentManager->getRepository('Doctrine\ODM\PHPCR\Document\Resource');
$this->documentManager->getRepository('Doctrine\ODM\PHPCR\Document\File');

we could add something to specify the document class in the child annotation, but this sounds stupid.

and getting a document without knowing its document class beforehand would be a nice feature in general. however, the info is currently scattered in annotations over the project. any idea how we could make phpcr-odm know all alias to document class mappings?

 Comments   
Comment by David Buchmann [ 23/Jun/11 ]

to implement extracting the mapping, assetic:dump might give some inspiration. in dev mode, we should extract automatically (maybe with some cache lifetime, depending on how expensive that is - its less obvious than what assetic can do)

it would be something like getAllMetadata in our case, then cache it.

Comment by David Buchmann [ 23/Jun/11 ]

according to benjamin, mongo-odm uses an attribute targetDocument that is set to the document class, so the annotation seems not such a bad idea after all.

not sure how to handle a case when we have children with varying document classes, though. but targetDocument would be a start, and cover many common cases.

Comment by David Buchmann [ 23/Jun/11 ]

after more dicussion with benjamin: in mongo, benjamin does no longer store an alias but directly the document class. we could also do that.

Comment by Uwe Jäger [ 24/Jun/11 ]

As you say this is more an issue with the meta-data handling within the odm. The same issue will apply to references and to parent and children annotations I guess. Storing the class directly and loading the meta-data via the class when needed seems a good solution to me.

Comment by David Buchmann [ 24/Jun/11 ]

we now store the phpcr:class instead of phpcr:alias. the alias is still supported for legacy.

https://github.com/doctrine/phpcr-odm/pull/45




[PHPCR-31] add support for metadata caching Created: 22/Oct/11  Updated: 28/Dec/11  Resolved: 28/Dec/11

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Lukas Kahwe Assignee: Jordi Boggiano
Resolution: Fixed Votes: 0
Labels: None


 Comments   
Comment by Marco Pivetta [ 26/Dec/11 ]

For reference, this is being handled at https://github.com/doctrine/phpcr-odm/pull/85

Comment by Lukas Kahwe [ 28/Dec/11 ]

merged




[PHPCR-19] Code cleanup and refactoring, align to other odm implementations Created: 30/Jul/11  Updated: 30/Jul/11  Resolved: 30/Jul/11

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: David Buchmann Assignee: Jordi Boggiano
Resolution: Duplicate Votes: 0
Labels: None


 Description   

Refactor the code to share more code with mongodb and other ODM implementations. Can we extract stuff into common base classes or adjust mongo so we can extend from it? The current code is often copy-paste with some small edits all over which makes it hard to update with new features and bugfixes from mongodb.

Also have a look at the OXM - we probably could profit from collaboration there too, as PHPCR is somewhere between document store and XML database. http://www.doctrine-project.org/blog/doctrine-oxm-intro

Implement ObjectManager interface and maybe add to the common interfaces like findMany suitable for us.

 Comments   
Comment by David Buchmann [ 30/Jul/11 ]

this is tracked here DCOM-28




[PHPCR-83] make the test suite run and pass with Doctrine DBAL Created: 22/Oct/12  Updated: 11/Jan/13  Resolved: 11/Jan/13

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Lukas Kahwe Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
relates to PHPCR-47 make it possible to disable exception... Resolved

 Description   

this will likely require some work to disable certain tests relying on features not yet implemented

 Comments   
Comment by Lukas Kahwe [ 10/Jan/13 ]

actually already fixed with the latest changes in phpcr-utils
the issue is that we currently require 1.0-beta3
https://github.com/phpcr/phpcr-utils/compare/1.0-beta3...master#L21R519

Comment by Lukas Kahwe [ 11/Jan/13 ]

https://travis-ci.org/doctrine/phpcr-odm




[PHPCR-79] metadata type for non-property mappings Created: 03/Sep/12  Updated: 14/Jan/13  Resolved: 14/Jan/13

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: David Buchmann Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None


 Description   

(this is a follow up of https://github.com/sonata-project/SonataDoctrinePhpcrAdminBundle/issues/56)

ClassMetadata::mapField does not automatically assign a type except for the id field. we should add them here to have type information for things like nodename so for example sonata admin (or the symfony form builder?) can use that information to decide on the widget to use.

open question: is there a natural type mapping for children/parent? should we use MANY_TO_ONE for parent and ONE_TO_MANY for children? or is that a problem as its not arbitrary relations, should we add new types for this?



[PHPCR-78] Exception "Can't remove the protected property: jcr:created" on persist Created: 10/Aug/12  Updated: 30/Aug/12  Resolved: 30/Aug/12

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: damien pitard Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None
Environment:
  • phpcrodm #fc47314043805c1b8d1e998d534abec75874a8e5
  • jackalope #6de09e160a2d56b34d34e8120a254fbe46892fb7
  • jackalope-jackrabbit #3c4fb61bf0c0664d09ef520683842e6426c033e0


 Description   

When a Document contains a reference field (tested with @ReferenceMany(strategy="hard"), @ReferenceOne(strategy="hard")) and a "jcr:created" field in its metadata, then phpcr-odm try to update the protected field (jcr:created) to NULL on persist.

Jackalope throws the following exception :

[PHPCR\NodeType\ConstraintViolationException]
Can't remove the protected property: jcr:created

 Comments   
Comment by damien pitard [ 28/Aug/12 ]

here's a functional test to reproduce the bug https://github.com/pitpit/phpcr-odm/commit/a7e1ba83d78771599181d2dee3c03c5163cf26e7

Comment by Lukas Kahwe [ 30/Aug/12 ]

fixed by https://github.com/doctrine/phpcr-odm/pull/158




[PHPCR-52] lazy loading of ReferenceMany fails Created: 15/Feb/12  Updated: 22/Feb/12  Resolved: 22/Feb/12

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Christian Stocker Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None


 Description   

When I have a document with ReferenceMany "Links", Doctrine PHPCR always loads all those referenced documents, even if I just load the main document. This is obviously very bad for performance.

https://gist.github.com/1838831
is a reproducible use-case. Just ran it twice and you'll see that in the second run, there is

  • one GET request for the initial documents
  • a REPORT request for every referenced document to resolve the UUID to a path
  • a POST request for multi-get-ing all the referenced documents

See also this charles-screenshot
https://img.skitch.com/20120215-8572c4s5mc8gt2da5wjd71512w.jpg

I have no idea where to look at to fix this, so any help would be very appreciated



[PHPCR-53] repository::createDocument is never called Created: 18/Feb/12  Updated: 22/Feb/12  Resolved: 22/Feb/12

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: David Buchmann Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None


 Description   

i tried using repositories. see

https://github.com/symfony-cmf/ChainRoutingBundle/commit/12515f82b02c4a1ef230b05133ec89e03c1af2e0
https://github.com/symfony-cmf/ChainRoutingBundle/commit/edd9f9544eadedb142fefd3ea9bb0c3b293c59d5

however, from looking at the uow code i have the impression that createDocument is never called on DocumentRepository but directly in UOW. shouldn't the uow fetch the repository and build the document with the repository? effectively moving UOW::createDocument impl. to the base repository?

 Comments   
Comment by Lukas Kahwe [ 18/Feb/12 ]

none of the other ODM/ORM seem to have a create*() method in the repository. i suspect using a listener is the right approach and we should remove that method from the DocumentRepository.

Comment by Lukas Kahwe [ 22/Feb/12 ]

removed the method




[PHPCR-51] make it possible to add attributes to type mappings Created: 13/Feb/12  Updated: 16/Feb/12  Resolved: 16/Feb/12

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Lukas Kahwe Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None


 Description   

f.e. make it possible to make a string mapped typed translatable inside an inherited class
this will require modifications to the ClassMetadata class:
https://github.com/doctrine/phpcr-odm/blob/master/lib/Doctrine/ODM/PHPCR/Mapping/ClassMetadata.php#L578

 Comments   
Comment by David Buchmann [ 14/Feb/12 ]

see https://github.com/doctrine/phpcr-odm/pull/105

Comment by Lukas Kahwe [ 16/Feb/12 ]

fixed with 115f1961600e6cd4fedbec30f1c7590a4d375d57




[PHPCR-50] fix handling of children on update Created: 13/Feb/12  Updated: 12/Apr/12  Resolved: 12/Apr/12

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Lukas Kahwe Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None


 Description   

right now we do not check if individual elements in the collection have been added or removed. furthermore since we can now update the order of children in jackalope, we can implement this in collection persistence as well.

 Comments   
Comment by Lukas Kahwe [ 15/Feb/12 ]

some initial work
https://github.com/doctrine/phpcr-odm/commit/a2dc3bc827ded1f54c7bd4708c4e495935ad39e5

Comment by Lukas Kahwe [ 10/Apr/12 ]

adding/removing is now implemented, reordering is still missing (see https://github.com/doctrine/phpcr-odm/tree/children_updating)




[PHPCR-49] rewrite DocumentRepository::createQuery() to use QOM Created: 08/Feb/12  Updated: 10/Feb/12  Resolved: 10/Feb/12

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Lukas Kahwe Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None


 Description   

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



[PHPCR-47] make it possible to disable exceptions for phpcr implementations without versioning support Created: 06/Feb/12  Updated: 14/Nov/12  Resolved: 14/Nov/12

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Lukas Kahwe Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
is referenced by PHPCR-83 make the test suite run and pass with... Resolved

 Description   

so method calls to checkPoint() etc shouldn't fail. full versioning should just set referenceable etc.

 Comments   
Comment by Lukas Kahwe [ 14/Nov/12 ]

https://github.com/doctrine/phpcr-odm/pull/188




[PHPCR-42] sync the xml/yml mapping driver with the annotation driver Created: 25/Jan/12  Updated: 17/Aug/12  Resolved: 17/Aug/12

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Lukas Kahwe Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None


 Description   

especially the locale/version stuff is not yet supported. but also the reference mapping seems to look quite different.

 Comments   
Comment by David Buchmann [ 02/Feb/12 ]

versioning is done now: https://github.com/doctrine/phpcr-odm/pull/96

but we miss tests for the non-annotation mappings

Comment by David Buchmann [ 07/Feb/12 ]

how to proceed:

Comment by David Buchmann [ 13/Feb/12 ]

initial test for annotations is added here, please evolve from this
https://github.com/doctrine/phpcr-odm/commit/38f8bbc8b655aafd099287e18401248c44b40492

Comment by Luis Cordova [ 15/Apr/12 ]

hi dbu, lsmith, i gave thought to this and did some corrections https://github.com/doctrine/phpcr-odm/pull/133

however I am totally disoriented as i see two Mapping folders as follows:

1. https://github.com/doctrine/phpcr-odm/tree/master/tests/Doctrine/Tests/ODM/PHPCR/Functional/Mapping
There is only 1 class here with a TODO which i found not very clear about what to do next

2. https://github.com/doctrine/phpcr-odm/tree/master/tests/Doctrine/Tests/ODM/PHPCR/Mapping
These set of classes was already refactored by someone else before I came in and I guess the work is done

I check the coverage as you said on the annotation driver class so it basically lacks the lifecycle callbacks usage, but where to put these tests in as i am confused


160 0 : if ($annot instanceof ODM\PrePersist) { 161 0 : $metadata->addLifecycleCallback($method->getName(), Event::prePersist); 162 0 : } elseif ($annot instanceof ODM\PostPersist) { 163 0 : $metadata->addLifecycleCallback($method->getName(), Event::postPersist); 164 0 : } elseif ($annot instanceof ODM\PreUpdate) { 165 0 : $metadata->addLifecycleCallback($method->getName(), Event::preUpdate); 166 0 : } elseif ($annot instanceof ODM\PostUpdate) { 167 0 : $metadata->addLifecycleCallback($method->getName(), Event::postUpdate); 168 0 : } elseif ($annot instanceof ODM\PreRemove) { 169 0 : $metadata->addLifecycleCallback($method->getName(), Event::preRemove); 170 0 : } elseif ($annot instanceof ODM\PostRemove) { 171 0 : $metadata->addLifecycleCallback($method->getName(), Event::postRemove); 172 0 : } elseif ($annot instanceof ODM\PostLoad) { 173 0 : $metadata->addLifecycleCallback($method->getName(), Event::postLoad); 174 0 : }

Also i am not very familiar with the schema of the annotation driver how to test so any explanation or help pointers would be great, thanks

Comment by Luis Cordova [ 15/Apr/12 ]

I am so not using jira sorry guys, ---> https://github.com/doctrine/phpcr-odm/pull/133

Comment by David Buchmann [ 09/Jun/12 ]

@craigmarvelley started working on this, promised a pull request soon

Comment by Craig Marvelley [ 11/Jun/12 ]

I've opened a PR here, there's still a bit left to be done that I'm hoping to add in the next few days.

https://github.com/doctrine/phpcr-odm/pull/144

Comment by David Buchmann [ 20/Jun/12 ]

the pull request by craig has meanwhile been merged.

there is still a bit of issues:

the driver looks for the non-namespaced file. i.e. No mapping file found named '/home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony-cmf/routing-extra-bundle/Symfony/Cmf/Bundle/RoutingExtraBundle/Resources/config/doctrine/Route.phpcr.xml' for class 'Symfony\Cmf\Bundle\RoutingExtraBundle\Document\Route'.

but if i put that file there and have an error, he tells me Invalid mapping file 'Symfony.Cmf.Bundle.RoutingExtraBundle.Document.Route.phpcr.xml'

so the name determiner seems to be off a bit

Comment by David Buchmann [ 18/Jul/12 ]

also, the mapped superclass feature makes no sense with phpcr-odm, we can simply inherit from document classes.

Comment by David Buchmann [ 20/Jul/12 ]

actually mapped superclass seems to be relevant, but i did not yet understand it and the doc about it should be updated. see discussion in https://github.com/doctrine/phpcr-odm/pull/144#issuecomment-7095570

Comment by Lukas Kahwe [ 17/Aug/12 ]

seems to me like reference/referrer/translation/versioning is all done .. so if there is anything left .. please open a new ticket




[PHPCR-37] update for latest doctrine common features Created: 14/Dec/11  Updated: 28/Dec/11  Resolved: 28/Dec/11

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Lukas Kahwe Assignee: Jordi Boggiano
Resolution: Fixed Votes: 0
Labels: None


 Description   

see

https://github.com/doctrine/common/pull/71
https://github.com/doctrine/common/pull/75
https://github.com/doctrine/common/pull/83
https://github.com/doctrine/common/commit/07d2f04408534f0870d9873a420e294a4b0db439 (done)

as well as https://github.com/doctrine/couchdb-odm/commit/56f4ce911c9fd7cf32547a9d454141f250c9de54 (done)

 Comments   
Comment by Lukas Kahwe [ 22/Dec/11 ]

some steps already done by https://github.com/doctrine/phpcr-odm/pull/84

Comment by Marco Pivetta [ 23/Dec/11 ]

Will start working on it tomorrow

Comment by Marco Pivetta [ 25/Dec/11 ]

I started work here https://github.com/Ocramius/phpcr-odm/compare/sync-doctrine-common-metadata-changes

Please notice that I removed a public method (loadMetadataForAlias, I think) from the ClassMetadataFactory.

Also, I'd love to have some help in understanding what Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory#doLoadMetadata($class, $parent, $rootEntityFound) should look like when implemented.

Comment by Marco Pivetta [ 26/Dec/11 ]

For reference, this is being handled at https://github.com/doctrine/phpcr-odm/pull/85

Comment by Lukas Kahwe [ 28/Dec/11 ]

merged




[PHPCR-35] referenced documents need to be referenceable Created: 15/Nov/11  Updated: 28/Dec/11  Resolved: 28/Dec/11

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: David Buchmann Assignee: Jordi Boggiano
Resolution: Fixed Votes: 0
Labels: None


 Description   

currently documents referenced need to have referenceable=true in their document annotation, otherwise the @ReferenceOne silently fails. (see also https://github.com/symfony-cmf/cmf-sandbox/pull/29 )

either phpcr-odm should complain. or it could just add the mix:referenceable to the target document even though it was not declared referenceable.
we could additionally make referenceable=true the default and offer explicit referenceable=false for optimization.

 Comments   
Comment by Uwe Jäger [ 15/Nov/11 ]

I will cover the first part for now, let phpcr -odm complain ...

Comment by Uwe Jäger [ 15/Nov/11 ]

This fixed now, but I can't close that issue ...




[PHPCR-34] replacing a document fails Created: 13/Nov/11  Updated: 22/Feb/12  Resolved: 22/Feb/12

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: David Buchmann Assignee: Jordi Boggiano
Resolution: Fixed Votes: 0
Labels: None


 Description   

when we have a saved document and remove that, then add a document at the same path without a flush in between, we get an exception. the reason is that persist already adds the phpcr node, but scheduleRemove does not remove the phpcrnode right away.

the fix looks like it should be:
UnitOfWork.php 504 remove phpcr node - 1022 do not remove here as it was removed before.

but this leads to a problem that is either in jackalope or the phpcr-odm about /functional/user/phpcr:class being not found.

1) Doctrine\Tests\ODM\PHPCR\Functional\BasicCrudTest::testRemoveAndInsert
PHPCR\ItemExistsException: This node already has a child named user.

/home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Node.php:303
/home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/Doctrine/ODM/PHPCR/UnitOfWork.php:763
/home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/Doctrine/ODM/PHPCR/UnitOfWork.php:404
/home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/Doctrine/ODM/PHPCR/UnitOfWork.php:386
/home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/Doctrine/ODM/PHPCR/DocumentManager.php:312
/home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/tests/Doctrine/Tests/ODM/PHPCR/Functional/BasicCrudTest.php:152

 Comments   
Comment by Lukas Kahwe [ 17/Nov/11 ]

imho this is now fixed. it will throw an \InvalidArgumentException that the document is detached. I have added relevant tests.

i have also created a ticket to add something to the persistence interfaces to make it possible to ensure that a node is cleared back to defaults for all fields not being persisted: http://www.doctrine-project.org/jira/browse/DCOM-77

Comment by David Buchmann [ 23/Jan/12 ]

i still have a problem with this. doing

if ($old_node = $this->dm->find(null, $path))

{ $this->dm->remove($old_node); }

$menuitem = new MultilangMenuItem();
$menuitem->setPath($path);
$menuitem->setName($name);
$menuitem->setLabel($label);

$this->dm->persist($menuitem);
return $menuitem;

leads to an exception. but imo i should be able to do this? what if i want to change the type of document at this location?

InvalidArgumentException
Detached document passed to persist().

Exception trace:
() at /home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/Doctrine/ODM/PHPCR/UnitOfWork.php:444
Doctrine\ODM\PHPCR\UnitOfWork->doScheduleInsert() at /home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/Doctrine/ODM/PHPCR/UnitOfWork.php:414
Doctrine\ODM\PHPCR\UnitOfWork->scheduleInsert() at /home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/Doctrine/ODM/PHPCR/DocumentManager.php:447
Doctrine\ODM\PHPCR\DocumentManager->persist() at /home/david/liip/symfony-cmf/cmf-sandbox/src/Sandbox/MainBundle/Resources/data/fixtures/030_LoadMenuData.php:90
Symfony\Cmf\Bundle\MenuBundle\Resources\data\fixtures\LoadMenuData->createMenuItem() at /home/david/liip/symfony-cmf/cmf-sandbox/src/Sandbox/MainBundle/Resources/data/fixtures/030_LoadMenuData.php:43
Symfony\Cmf\Bundle\MenuBundle\Resources\data\fixtures\LoadMenuData->load() at /home/david/liip/symfony-cmf/cmf-sandbox/vendor/doctrine-data-fixtures/lib/Doctrine/Common/DataFixtures/Executor/AbstractExecutor.php:94
Doctrine\Common\DataFixtures\Executor\AbstractExecutor->load() at /home/david/liip/symfony-cmf/cmf-sandbox/vendor/doctrine-data-fixtures/lib/Doctrine/Common/DataFixtures/Executor/PHPCRExecutor.php:55
Doctrine\Common\DataFixtures\Executor\PHPCRExecutor->execute() at /home/david/liip/symfony-cmf/cmf-sandbox/vendor/bundles/Doctrine/Bundle/PHPCRBundle/Command/LoadFixtureCommand.php:86
Doctrine\Bundle\PHPCRBundle\Command\LoadFixtureCommand->execute() at /home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony/src/Symfony/Component/Console/Command/Command.php:237
Symfony\Component\Console\Command\Command->run() at /home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony/src/Symfony/Component/Console/Application.php:193
Symfony\Component\Console\Application->doRun() at /home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:75
Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony/src/Symfony/Component/Console/Application.php:106
Symfony\Component\Console\Application->run() at /home/david/liip/symfony-cmf/cmf-sandbox/app/console:16

Comment by Lukas Kahwe [ 02/Feb/12 ]

I guess this is related to adding DocumentManager::merge()
http://www.doctrine-project.org/jira/browse/PHPCR-13

Comment by Lukas Kahwe [ 22/Feb/12 ]

duplicate of http://www.doctrine-project.org/jira/browse/PHPCR-13




[PHPCR-69] persist referrers Created: 04/Jun/12  Updated: 11/Jan/13  Resolved: 11/Jan/13

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: David Buchmann Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None


 Description   

phpcr knows reference and referrer (backlink). the reference is a property of a node with a defined name. the referrer is an information on the node without a property name in PHPCR. we have the annotation @Referrers to map this information onto a document field. the annotation can take an optional filter argument to only use references pointing to this node with a specific phpcr name.

we could add something like the cascade option found in the orm to allow assigning a document to a referrer property and automatically persist it. we will need to explicitly specify the reference property name to be used on the source document in this case (orm uses mappedBy for this)

github user mdekrijger started working on this. today, he wrote: Adding the annotations was quite easy, still figuring out the unitofwork where the actual processing must be implemented. Currently I can't spend much more time on it until end of june. If it isn't done yet by that time, I surely will pick it up from there.

 Comments   
Comment by M. de Krijger [ 27/Jun/12 ]

Could someone assign this to me? If not I will just comment this issue when new info is available

Comment by Lukas Kahwe [ 30/Aug/12 ]

hmm .. bah i guess its not possible to assign the ticket for you unless someone upgrades your account for which i dont have the permissions .. so just keep commenting i guess

Comment by Lukas Kahwe [ 09/Jan/13 ]

i guess this is now fixed?

Comment by David Buchmann [ 10/Jan/13 ]

yes, i think so. you implemented that with the cascading configuration options, didn't you?

Comment by Lukas Kahwe [ 11/Jan/13 ]

yes .. referrer changes are cascaded with control over the cascading




[PHPCR-70] ContentDocument Relationships returning NULL in Action Created: 06/Jun/12  Updated: 21/Jul/12  Resolved: 21/Jul/12

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Freddy H. Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None


 Description   

So i have 2 Documents:

Page: http://pastebin.com/b5X32JPc

Category: http://pastebin.com/A1gB6kyg

A Category has many pages.

Now here's my (test) action: http://pastebin.com/ypjxqZPu

As you can see, $contentDocument is a page in this case. If i call $contentDocument->category i get back "null".

If however i tell the document manager to fetch the Page document by it's path, then $contentDocument->category will work...

Our conclusion is that if you take the $contentDocument that is passed to your action, and you try to fetch it's ParentDocument inside the action (mapped to a property) you always get null.
However, what is very weird, is that inside twig it works (page.category would work in twig but page->category would return null inside the action, before the twig render)

 Comments   
Comment by David Buchmann [ 06/Jun/12 ]

this might be a bug of combining reference with parent.

[23:06] <dbu> look at vendor/doctrine/phpcr-odm/tests/Doctrine/Tests/ODM/PHPCR/Functional/HierarchyTest.php
[23:07] <dbu> and create a new test that tries to load node C, follow its reference to node B and check if its parent A is not null

Comment by Lukas Kahwe [ 21/Jul/12 ]

i have managed to reproduce the bug .. i am looking into fixing it now.

Comment by Lukas Kahwe [ 21/Jul/12 ]

fixed in master




[PHPCR-62] avoid dereferencing proxies on save Created: 05/Apr/12  Updated: 10/Apr/12  Resolved: 10/Apr/12

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: David Buchmann Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None


 Description   

chregu found in a large project that the odm seems to resolve all unresolved proxy documents during flush, even if the @ReferenceMany or @Referrer was not touched by the code.

we should make sure this does not happen.



[PHPCR-90] referrer delete and cascade delete Created: 19/Feb/13  Updated: 12/Mar/13  Resolved: 12/Mar/13

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: David Buchmann Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None


 Description   

currently, removing an entry from the referrer collection has no effect, nothing is deleted.

without cascading, we should delete the value from the referencing property (needs the filter(mappedBy) attribute again), with cascading we should delete the referencing document.

see also https://github.com/doctrine/phpcr-odm/pull/234

 Comments   
Comment by David Buchmann [ 19/Feb/13 ]

adding something to the referrers collection is also not taken into account atm.

Comment by David Buchmann [ 12/Mar/13 ]

https://github.com/doctrine/phpcr-odm/pull/252




[PHPCR-107] Support for ->sameNode type queries in QueryBuilder/ExpressionBuilder Created: 20/Apr/13  Updated: 25/Apr/13  Resolved: 25/Apr/13

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Daniel Leech Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: 1.0


 Description   

We should support sameNode operator of the QOMFactory in the QueryBuilder.

An example using the PHPCR QB from the DoctrinePHPCRAdminBundle:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
        $qb = $queryProxy->getQueryBuilder();
        $qmf = $qb->getQOMFactory();

        $constraint = null;
        foreach ($idx as $id) {
            $path = $this->getBackendId($id);
            $condition = $qmf->sameNode($path);
            if ($constraint) {
                $constraint = $qmf->orConstraint($constraint, $condition);
            } else {
                $constraint = $condition;
            }
        }
        $qb->andWhere($constraint);


 Comments   
Comment by Daniel Leech [ 25/Apr/13 ]

https://github.com/doctrine/phpcr-odm/pull/280




[PHPCR-28] figure out proper handling of types in DocumentManager::quote() Created: 10/Oct/11  Updated: 22/Feb/12  Resolved: 22/Feb/12

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Minor
Reporter: Lukas Kahwe Assignee: Jordi Boggiano
Resolution: Fixed Votes: 0
Labels: None




[PHPCR-13] Implement DocumentManager::merge() Created: 30/Jul/11  Updated: 09/Jan/13  Resolved: 09/Jan/13

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Lukas Kahwe Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None


 Comments   
Comment by David Buchmann [ 22/Oct/12 ]

see also https://github.com/doctrine/phpcr-odm/pull/184

Comment by Lukas Kahwe [ 04/Jan/13 ]

see also https://github.com/doctrine/phpcr-odm/pull/205

Comment by Lukas Kahwe [ 09/Jan/13 ]

205 was merged ..




[PHPCR-55] Add mapping for maps/associative arrays Created: 23/Feb/12  Updated: 26/Feb/12  Resolved: 26/Feb/12

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Uwe Jäger Assignee: Lukas Kahwe
Resolution: Duplicate Votes: 0
Labels: None


 Description   

Add a mapping for maps or arrays. Either implement as child node or serialize the array to a string. The first approach needs another node being fetched from the repository but allows to search the array.

 Comments   
Comment by Uwe Jäger [ 26/Feb/12 ]

see issue #PHPCR-56




[PHPCR-72] persist cancels move Created: 19/Jun/12  Updated: 21/Jul/12  Resolved: 21/Jul/12

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Freddy H. Assignee: Lukas Kahwe
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

If i have a node that i fetch from the repo using $dm->find()

If i change an attribute in it.
Then i call $dm->move() on it

Then i call $dm->flush().

It will work.

However if i call $dm->persist() on the node (that i already fetched from $dm->find()) and then call $dm->flush()
The $dm->move() won't occur, it will be cancelled, but the attribute i changed will still be updated.

 Comments   
Comment by Lukas Kahwe [ 20/Jul/12 ]

i have to think about if this is a bug or a feature.
its certainly useful to have a way to "cancel" operations ..
f.e. persist() also cancels remove()

then again persist() is i guess viewed by many as a non problematic operation since it commonly doesn't break anything if one persisted an object multiple times.

Comment by Lukas Kahwe [ 21/Jul/12 ]

as i expected this is an intentional feature:
https://github.com/doctrine/phpcr-odm/blob/master/lib/Doctrine/ODM/PHPCR/UnitOfWork.php#L518

we could think about adding a dedicated method to "reset" the state, but the ORM doesn't have something like that so i rather not introduce it.




[PHPCR-68] Versionable Item completely loses references Created: 01/Jun/12  Updated: 22/Jul/12  Resolved: 22/Jul/12

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Freddy H. Assignee: Lukas Kahwe
Resolution: Cannot Reproduce Votes: 0
Labels: None


 Description   

I have a post that has a reference to a subcategory

When i made my post versionable="full", the current and old versions of post lost this reference.

So when i call $post->subcategory i get back a Generic ODM document instead of a Subcategory Document

I know that relationships are not versionable, but relationships should at least still exist.

The workaround is to get the parent path and make a JCR-SQL2 query to fetch the subcategory document.

 Comments   
Comment by David Buchmann [ 01/Jun/12 ]

note that this could also be a problem in jackalope. we seem to have issues with the frozenNode thing (either in the implementation or in the correct understanding) https://github.com/jackalope/jackalope-jackrabbit/issues/19

Comment by Lukas Kahwe [ 22/Jul/12 ]

please reopen once you have a reproduceable test case, thx




[PHPCR-67] Fetching a node beforehand ruins ordering of collections Created: 25/May/12  Updated: 22/Jul/12  Resolved: 22/Jul/12

Status: Resolved
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Freddy H. Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None


 Description   

Two documents: Category and Subcategory
Category has $subcategories as a PHPCRODM\Children

If Category A has 3 subcategories B1 B2 B3.

If A's subcategories are fetched we would receive them in the following order: B1 B2 B3.

Now if however we fetched the B2 node using the DocumentManager at an earlier line and then fetched the subcategories of A, we would receive them in the following order:
B2 B1 B3

 Comments   
Comment by Lukas Kahwe [ 12/Jun/12 ]

i tried to reproduce the issue in a test case:
https://github.com/doctrine/phpcr-odm/commit/7a3f690cd407f5fc75af4ae3d70b4360c5a499c7

however the test passes. so either the issue is already fixed or i just didn't understand the bug description properly.




Generated at Thu May 23 16:19:51 UTC 2013 using JIRA 5.2.7#850-sha1:b2af0c8dc8537b36121c6a579fabbdf79fc919e5.