after merge #314 (maybe)
sorry i not update long time

class extends AbstractFile - unable to create

error

Field 'created' of class 'Irev\EditorBundle\Document\Rio' is not nullable

see doctrine/DoctrineBundle#221

When renaming a node in the Sonata Admin from "main" to "Main" I get:

 ItemExistsException: Cannot move '/cms/pages/main' to '/cms/pages/Main' because destination node already exists

I guess this is a PHCR-ODM issue.

The dependency "phpcr/phpcr-implementation" cannot be resolved when using composer. It would seem that phpcr/phpcr-implementation does not exist anywhere that I can find..?

Is this dependency required any longer?

I often rely on behavior like this, which is consistent with the ORM package:

    if (!($myDocument = $documentManager->find('My\Document', $uuid))) {
        // handle not found, e.g. specific 404
    }

This assumes that the DocumentManager::find() method is handling exceptions from the PHPCR implementation and then returning null if the requested document is not found. Instead, right now in master we are getting a PHPCR\ItemNotFoundException bubbling up through find() that must be handled by the caller.

It is unclear to me if this is the correct, intended behavior, or if there is just a missing catch there.

I'd love to see this behave similarly to the ORM's EntityManager::find() to keep a consistent code style throughout an application that mixes both.

Both the ORM and MongoDB ODM have a command which creates getters and setters, based on the mapping data. The PHPCR ODM should also provide something this command.

I'm in doubt what the command name should be. The ORM uses orm:generate:entities and the MongoDB ODM uses odm:generate:documents. Some suggestions:

• odm:generate:documents (duplicate, but it's the most logical)
• phpcr:generate:documents (simple and descriptive, but sounds like it's something from phpcr/phpcr and not doctrine/phpcr-odm)
• phpcr-odm:generate:documents (best option, but a very long command)

For the last 2 suggestions, I would prefer to rename the MongoDB ODM command too.

I'll start working on this one, but I would like to discuss the best name.

as discussed in #268 we should implement UnitOfWork::isScheduledDocument and isScheduledFor* other than isScheduledForInsert.

When persisting documents that include the Jackalope node in the mapped fields the node is null in the originalData of the UnitOfWork after flushing. Therefore when flushing again, the documentChangeset for that document is not empty.

The autoname id strategy could use some tweaks:

• A way to specify an optional nameHint for addNodeAutoNamed
• The strategy should check if there is a nodename field mapped on the document and if that is non-empty and only generate a name if the field is not set.
• We could add a way to slugify other fields, for example using the symfony ExpressionLanguage. that would be phpcr-odm only and not use the phpcr way of autocreating a nodename.

Hello.

I try rename nodes by changing nodenames, but it does not work stably.

This test "Failed asserting that actual size 0 matches expected size 1." on last count check
jekill@15f986d
Thus it must be?

Hi,
I'm working with a set of 3 documents - let's say Container, AbstractChild, ChildImpl classes.
The Container class has a mychildren property being a collection of AbstractChild implementations (i.e. ChildImpl instances).
I want the container and abstract child documents to use an 'auto' generated ID.
I expect the container to have a path like '/[...]/containerId', and child documents '/[...]/containerId/childId'.
These documents have this YAML mapping:

Container:
  id:
    fieldName: 'path'
    generator:
      strategy: 'auto'
  parentdocument: 'parentDocument'
  children:
    mychildren:
      cascade: ['persist']

AbstractChild:
  mappedsuperclass: true
  id:
    fieldName: 'path'
    generator:
      strategy: 'auto'

ChildImpl:
  fields:
    myproperty:
      type: 'string'

id generation is OK for the Containerdocument.
When persisting the Container document, with the 'cascade' property, mychildren are also persisted.
But I got an error: the UnitOfWork (line 752) complain the nodename property may not be empty in document of class AbstractChild.

I found this really strange because I set the ID strategy to 'auto' in the AbstractChild document. Finally, after code analysis, it seems this is due to the code located at Doctrine\ODM\PHPCR\UnitOfWork.php (748:755).
It seems that children properties can use only 'assigned' ID strategy. Whatever strategy is configured, the 'assigned' one will override it.

Can you confirm the ODM doesn't support 'auto' ID strategy with children properties?
Thus this would not be a real issue, more an 'incomplete' docs issue ;).
Documentation is a bit obscur about how to configure children documents, especially with the 'Id', 'NodeName' and 'ParentDocument' settings (see http://docs.doctrine-project.org/projects/doctrine-phpcr-odm/en/latest/reference/annotations-reference.html#children).
If I use the 'assigned' ID strategy, setting the nodename manually, persisting the container document and the children works well :).
Thanks for your clarifications, and any remarks about what I'm trying to do!
BR.

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

relates to #380 and #381

The Join support in the query builder is currently disactivated - as I am unsure about the implementation.

git clone [email protected]:doctrine/phpcr-odm.git
cd phpcr-odm
./tests/travis_doctrine_dbal.sh

results in the following error:

  Problem 1
    - jackalope/jackalope-doctrine-dbal 1.0.0-beta3 requires jackalope/jackalope 1.0.0-beta4 -> satisfiable by jackalope/jackalope[1.0.0-beta4].
    - jackalope/jackalope-doctrine-dbal 1.0.x-dev requires jackalope/jackalope 1.0.0-beta4 -> satisfiable by jackalope/jackalope[1.0.0-beta4].
    - Conclusion: don't install jackalope/jackalope 1.0.0-beta4
    - Installation request for jackalope/jackalope-doctrine-dbal ~1.0.0-beta3 -> satisfiable by jackalope/jackalope-doctrine-dbal[1.0.0-beta3, 1.0.x-dev].

Not sure if I should report this to jackalope instead.

If someone encounters the same problem here’s a dirty fix for the composer json:

        "jackalope/jackalope":">=1.0.0-beta3",
        "jackalope/jackalope-doctrine-dbal":"*",
        "doctrine/dbal": ">=2.2.0,<2.4"

there is now a command to migrate a document from one class to an other, but this would be useful functionality through code as well.

https://github.com/doctrine/phpcr-odm/blob/master/lib/Doctrine/ODM/PHPCR/Tools/Console/Command/DocumentMigrateClassCommand.php

similar to #305 but for the reorderings. not sure if other things like move and remove should also be checked.

/cc @hacfi

Originally posted by @awdng as doctrine/DoctrinePHPCRBundle#98

While something like this works fine:

$dm->getRepository('ApplicationBiologicaMainBundle:CMS\Page')->findAll();

the equivalent

$qb->from()->document('ApplicationBiologicaMainBundle:CMS\Page', 'p');

just returns no results with no Exception.

Second example using the FQN works fine though.

(this issue was reported by Michael Lieser)

If i have a document at '/id' with class 'Right\Class' and load that with DocumentManager::find('Wrong\Class', '/id'), i get back an object, instead of the failure.

DocumentManager:find calls DocumentClassMapper:validateClassName but the code determining the original class is strange: https://github.com/doctrine/phpcr-odm/blob/master/lib/Doctrine/ODM/PHPCR/DocumentClassMapper.php#L43 - this means that if the requested class is not a subclass of the stored class, we just keep the requested class.

this can be considered a feature (i can load data in my class regardless of what is in the node) but imho it is rather confusing usually. can and should we do anything about this?

PHP Fatal error:  Call to undefined method Doctrine\Common\Collections\ArrayCollection::isDirty() in /home/daniel/www/symfony-cmf/RoutingAutoBundle/vendor/doc
trine/phpcr-odm/lib/Doctrine/ODM/PHPCR/UnitOfWork.php on line 2298

When initializing a class with an ArrayCollection in the constructor, e.g.

        $category = new Category();
        $category->path = '/test/category1';
        $category->title = 'category';
        $this->getDm()->persist($category);

        $article = new Article;
        $article->path = '/test/article-1';
        $article->categories->add($category);

        $this->getDm()->persist($article);
        $this->getDm()->flush();

The method name fieldExists makes no sense for a document, where the "field" refers to the class property, and therefore always "exists". Renaming this method to fieldIsset would make sense in the ODM.

Move all classes defined in DoctrineAnnotations into separate files in that namespace and have DoctrineAnnotations.php require all those files for BC compatibility.

This will get us rid of the requirement to do AnnotationRegistry::registerFile(__DIR__.'/../vendor/doctrine/phpcr-odm/lib/Doctrine/ODM/PHPCR/Mapping/Annotations/DoctrineAnnotations.php'); in the bootstrapping.

it seems we currently allow null values being stored even when the metadata says something can not be null. this is highly confusing.

also, since #304 we run into problem if non-nullable translated fields are stored as null (we find no translation in that case)

We ran into issues specifically with the DocumentManager->reorder method where if there had been a previous flush but you had not called clear then there was an exception thrown. This seems to be due to internal state of the DocumentManager queueing re-orders and this having an effect on subsequent calls to flush that involve a reorder. Its possible this is documented somewhere in the doctrine phpcr docs but I didnt see it. I found mentions to clear on this page

https://doctrine-phpcr-odm.readthedocs.org/en/latest/reference/working-with-objects.html?highlight=clear

Is there a reason why calling flush doesnt clear out the reorder queue? (im sure there is im guess im just saying i dont know why it doesnt).

When adding children that use auto-generated node names to a parent's children collection, each child is duplicated upon calling DocumentManager::flush().

Consider two documents, the first of which has only a collection of children:

use Doctrine\Common\Collections\ArrayCollection;
use Doctrine\ODM\PHPCR\Mapping\Annotations as PHPCRODM;

/**
 * @PHPCRODM\Document
 */
class ExampleParent
{
  /**
   * @PHPCRODM\ParentDocument
   */
  private $parent;

  /**
   * @PHPCRODM\Nodename
   */
  private $name;

  /**
   * @PHPCRODM\Children
   */
  private $details;

  public function __construct()
  {
    $this->name = 'example_parent';
    $this->details = new ArrayCollection();
  }

  // more stuff

}

And the second of which just stores some content:

use Doctrine\ODM\PHPCR\Mapping\Annotations as PHPCRODM;

/**
 * @PHPCRODM\Document
 */
class ExampleChild
{
  /**
   * @PHPCRODM\ParentDocument
   */
  private $parent;

  /**
   * @PHPCRODM\Id
   */
  private $id;

  /**
   * @PHPCRODM\String
   */
  private $content;

  public function __construct()
  {
  }

  // more code

}

Now, we can create a parent and add some children:

    // assume we have already retrieved $documentManager

    $exampleParent = new ExampleParent();
    $exampleParent->setParent($documentManager->find(null, '/'));

    $documentManager->persist($exampleParent);
    $documentManager->flush();

    // create some dummy children
    foreach (array('test_one', 'test_two', 'test_three') as $value) {

      $exampleChild = new ExampleChild();
      $exampleChild->setParent($exampleParent);
      $exampleChild->setContent($value);

      $exampleParent->getDetails()->add($exampleChild);

      $documentManager->persist($exampleChild);

    }

    echo '*** BEFORE FLUSH ***' . PHP_EOL;
    foreach ($exampleParent->getDetails() as $key => $detail) {
      echo $key . ': ' . $detail->getId() . ': ' . $detail->getContent() . PHP_EOL;
    }

    $documentManager->flush();

    echo PHP_EOL . '*** AFTER FLUSH ***' . PHP_EOL;
    foreach ($exampleParent->getDetails() as $key => $detail) {
      echo $key . ': ' . $detail->getId() . ': ' . $detail->getContent() . PHP_EOL;
    }

The result is not quite what we would expect!

*** BEFORE FLUSH ***
0: /example_parent/1929002033: test_one
1: /example_parent/599553769: test_two
2: /example_parent/286007372: test_three

*** AFTER FLUSH ***
0: /example_parent/1929002033: test_one
1: /example_parent/599553769: test_two
2: /example_parent/286007372: test_three
1929002033: /example_parent/1929002033: test_one
599553769: /example_parent/599553769: test_two
286007372: /example_parent/286007372: test_three

Before the DocumentManager::flush() operation, the ArrayCollection contains the three new Documents with non-specific indices. After the operation, the new node names are used as the indices, but the originals are not removed from the collection, resulting in a duplicate of each.

The offending code is in UnitOfWork::computeChangeSet() lines 1240-1247 as such:

$childNames = array();
if ($actualData[$fieldName]) {
    foreach ($actualData[$fieldName] as $nodename => $child) {
        $nodename = $this->getChildNodename($id, $nodename, $child, $document);
        $actualData[$fieldName][$nodename] = $this->computeChildChanges($mapping, $child, $id, $nodename, $document);
        $childNames[] = $nodename;
    }
}

It appears that the result of this block is that $actualData[$fieldName] will always end up with duplicated data if the node name changes as part of UnitOfWork::getChildNodename(), which is guaranteed if the child is new and uses a generated name.

It seems this could be fixed with a line of code to remove the old index upon insertion of the new one, but I am less familiar with the code as a whole so it's possible I am missing something or that this is intended (although it seems unlikely).

In the above sample code, if the $exampleParent->getDetails()->add($exampleChild); line is omitted, the children collection is never populated at all. This seems as though it may also be a bug, or perhaps just not yet implemented.

If these are in fact bugs I am happy to fix them and submit a pull request, I just don't want to do so without a better understanding of the intent.

At the moment using andWhere without an existing where will throw an Exception, we should change this to be valid behavior.

Hi,

It seems the UUID mapping documentation is not correct.
Documentation located at http://docs.doctrine-project.org/projects/doctrine-phpcr-odm/en/latest/reference/association-mapping.html#referenceable-documents mentions an invalid configuration to map the PHPCR UUID property on a property in a document class, with the YAML driver:

MyPersistentClass:
  referenceable: true
  uuid: uuid

I did exactly this very simple configuration, but never got my 'uuid' property populated after a 'persist' operation on the document manager.
After digging in the ODM code,
Doctrine\ODM\PHPCR\Mapping\ClassMetadata::mapField method
Doctrine\ODM\PHPCR\Mapping\Driver\YamlDriver::loadMetadataForClass method
it seems the right way to map a property (field) on the PHPCR UUID is to use this configuration:

MyPersistentClass:
    referenceable: true
    fields:
        uuid:
            uuid: true

I could get the 'uuid' property populated successfully with this configuration.

Please can you confirm this doc issue?
Thanks,
BR.

It should be possible to have an array type which automatically creates a structure, e.g

class Site {
    /**
     * @PHPCR\AssocArray()
     */
     protected $preferences;
}

Then automatically map that to a PHPCR structure:

/site
    preferences/
         - jcr:primaryType  = phpcr:associative_array
         - key1 = value 
         key2/
             - key3: = value
             - key4: = value
             key5/

Hi,

I am quit new to PHPCR ODM, so I guess I am doing something wrong.

I have this class:

namespace Acme\PHPCRBundle\Document;

use Doctrine\Common\Collections\ArrayCollection;
use Doctrine\ODM\PHPCR\Mapping\Annotations as PHPCR;

/**
 * @PHPCR\Document()
 */
class Page
{
    /**
     * @var string
     * @PHPCR\Id(strategy="parent")
     */
    protected $id;

    /**
     * @var string
     * @PHPCR\Nodename
     */
    protected $slug;

    /**
     * @var
     * @PHPCR\ParentDocument
     */
    protected $parent;

    /**
     * @var Page[]
     * @PHPCR\Children(fetchDepth=3)
     */
    protected $children;

    function __construct($slug, $parent)
    {
        $this->slug = $slug;
        $this->parent = $parent;
        $this->children = new ArrayCollection();
    }

    /**
     * @return \Acme\PHPCRBundle\Document\Page[]
     */
    public function getChildren()
    {
        return $this->children;
    }
}

Used the following fixture to load data:

$repository = $manager->getRepository('AcmePHPCRBundle:Page');
$root = $repository->find('/');

$cms = new Page('cms', $root);

$foo = new Page('foo', $cms);
$bar = new Page('bar-bar', $cms);
$baz = new Page('baz', $bar);

$manager->persist($cms);
$manager->persist($foo);
$manager->persist($bar);
$manager->persist($baz);

$manager->flush();

When displaying a treeview based on node cms, where for each node the id and slug properties are displayed, the expected output would be:

---- cms (cms)
    |--- cms/foo (foo) 
    |--- cms/bar-bar (bar-bar)
        |--- cms/bar-bar/baz (baz)

Instead, this is my output:

---- cms ()
    |--- cms/foo () 
    |--- cms/bar-bar ()

Problems:

• The objects properties are not set (except for the Id), I tested it with more properties
• $page->getChildren() works fine (it actually returns a collection with pages), but each child in this collection is not initalized and thus there are no grandchildren when calling $child->getChildren

Anyone? Thanks!

This function use to work.

I'm on "doctrine/phpcr-odm": "1.0.0-beta5",

Notice: Array to string conversion in /home/niko/www/PrestaConcept-Github/prestacms-sandbox/vendor/doctrine/phpcr-odm/lib/Doctrine/ODM/PHPCR/UnitOfWork.php line 1175

at this line

$child = $this->getDocumentById($id.'/'.$childName);

$childName contains one element like this 0 => 'childName' instead of a string

if document translation strategy is set to child then $childName contains one more element for every locales.

When installing the standard distribution, the executables in bin will not run.

PHP Fatal error:  Configuration file [/home/daniel/www/dantleech/basic-cms/cli-config.php] does not exist. See https://github.com/doctrine/phpcr-odm/wiki/Command-line-tool-configuration in /home/daniel/www/dantleech/basic-cms/vendor/doctrine/phpcr-odm/bin/phpcrodm.php on line 33
PHP Stack trace:
PHP   1. {main}() /home/daniel/www/dantleech/basic-cms/vendor/doctrine/phpcr-odm/bin/phpcrodm:0
PHP   2. include() /home/daniel/www/dantleech/basic-cms/vendor/doctrine/phpcr-odm/bin/phpcrodm:4
PHP   3. trigger_error() /home/daniel/www/dantleech/basic-cms/vendor/doctrine/phpcr-odm/bin/phpcrodm.php:33

However, the ORM standard edition executables do run out of the box.

To make it possible to reuse a query builder, clone should recursively clone all parts of the querybuilder.

similar to #353 but for child translation. with the recently merged join support, this should be possible with a ISCHILDNODE criteria.

then update the doc that was added here: doctrine/phpcr-odm-documentation#43

the querybuilder should check the alias that is passed in and complain if it is an empty string. i think the right place would be in SourceDocument
https://github.com/doctrine/phpcr-odm/blob/master/lib/Doctrine/ODM/PHPCR/Query/Builder/SourceDocument.php#L12

/cc @dantleech

At the moment the QueryBuilder uses both the "selector" and "alias" terminology to mean the same thing. Selector is PHPCR, Alias is Doctrine. We should choose one or the other.

I think if we stick with "alias" we should probably allow the FQN to be used instead of an alias.. e.g.

$qb->from('Blog\Post')->innerJoin()
    ->left()->document('Blog\Post')->end()
    ->right()->document('Blog\User')->end()
    ->condition()->...->end();
$qb->where()->eq()->field('Blog\Post.title')->literal('foo');

Hi,

I'm just trying to configure Doctrine PHPCR-ODM with multiple sessions, as shown in the Symfony CMF docs, but when I execute any Symfony command, such as 'php app\console cache:clear', I get the error below:

The service definition "doctrine_phpcr.odm.default_session.event_manager" does not exist.

First of all, I couldn't find any reference documentation in GitHub and the Doctrine Project website about the ODM configuration, it's really a pity.
Only Symfony CMF http://symfony.com/doc/current/cmf/bundles/phpcr_odm.html#configuring-multiple-sessions mentions (all?) the configuration options available, but I'm not even sure this is an updated revision.
Trying to figure out what's causing this error, I finally reduced my PHPCR configuration to the following, and still getting the same error:

doctrine_phpcr:
    session:
        default_session: mysession
        sessions:
            mysession:
                backend:
                    type: doctrinedbal
                    connection: myconnection
                    check_login_on_server: true
                workspace: default
                username: admin
                password: admin
    odm:
        default_document_manager: mydocumentmanager
        auto_generate_proxy_classes: %kernel.debug%
        document_managers:
            mydocumentmanager:
                session: mysession
                auto_mapping: true

Finally, if I replace 'mysession' and 'mydocumentmanager' references with 'default', the error disappears, but any other combination still leads to this error. It seems there is a remaining 'default' configuration hard-coded in the bundle.

Or maybe a 'default' named-session and a 'default' named-document manager are mandatory. Once again, it is not clear in the documentation, and if so I can't understand why there would be a 'default_session' key and a 'default_document_manager' key.

Thanks in advance for your clarifications, feel free to tell me what I've done wrong!
BR
Vicente

Apart from the fact that I keep typing "litreal" instead of "literal" I wonder if this is the best name, or if we should change it to value() while we still have a chance?

$where->eq()->field('a.foo')->literal('Foobar');
//to
$where->eq()->field('a.foo')->value('Foobar');
// and just for comparison, the other static operand...
$where->eq()->field('a.foo')->parameter('foobar');

TO be consistent with the ORM.

doctrine:phpcr:mapping:info says all is ok with my mappings, but when having for example @PHPCR\Referrers without any attributes, persisting or cache warmup leads to

The referrer field 'presentations' in 'Path\To\Document' is missing the required 
'referencedBy' attribute. If you want all referrers, use the immutable 
MixedReferrers mapping

We should provide a listener (and support that in the bundle too) that listens to preUpdate and prePersist and updates any documents that are mix:lastModified by looking for the jcr:lastModified field. phpcr implementations will not update that automatically, probably to allow the application to decide what changes require to update lastModified.

If you disable the listener, you would have to implement your own logic.

to make it possible to use other libs like https://github.com/ramsey/uuid

jackalope/jackalope-doctrine-dbal#164

Seems to be caused by #304

SimpleCms crashes when using the latest PHPCR-ODM, saying that PHPCR-ODM cannot find the default translation, or indeed any of the translations listed in the fallbacks.

The nodes are however correctly configured

      - phpcr_locale:en-title = Simple CMF
      - phpcr_locale:en-label = Simple Cmf
      - phpcr_locale:ennullfields = Array(    [0] => body)

and things work before #304 was merged. Any ideas?

I am currently working on a website based on Symfony CMF and have hit a wall with regard to querying documents through PHPCR-ODM.

What I am trying to do is query and sort a list of documents, but it seems the sorting is not working as expected. Here is my query:

    $dm = $this->get('doctrine_phpcr')->getManager();
    $qb = $dm->createQueryBuilder();
    $qb
        ->from()
            ->document('Acme\Bundle\SomeBundle\Document\Foo', 'f')
        ->end()
        ->orderBy()
            ->asc()
                ->field('f.title')
            ->end()
        ->end();

When I run this query the list of documents are not sorted as requested. But when I change the field "title" from being translated to non-translated then the sorting works almost as expected. So it seems sorting is broken when the referenced field is configured as a translated field.

Btw, I am using version the latest released version of phpcr-odm.

caching query results could improve the performance significantly.

once done, also update DoctrinePHPCRBundle to integrate the cache with symfony.

while investigating a website using phpcr-odm, i found that after setting a depth of 2 there are two things left that lead to a lot of unnecessary requests:

• parent / single child annotations always lead to getting that parent or child (parent won't be pre-fetched, child sometimes also not). the problem is that we do not know the class of the target, and thus can not create the correct proxy without having the node. i see 2 options:
  • we could allow to specify the class in the mapping. this is not always possible, and even if it is we might miss that a child / parent is of a subclass of the configured class. not very cool.
  • we could build a (persisted) cache of path => fqn class to build proxies without loading the node. this will however degrade performance if many of the child proxy are accessed (not with status quo, but i am preparing a PR to collect all child and the parent and fetch them with getNodes)
• referrers resolution has to be done with NodeInterface::getReferrers - PHPCR seems to offer no way to batch that, even if we would know this is going to happen. i wonder if we could cache that across requests as well. probably this should be cached on jackalope level, rather than in the odm, to be sure we properly invalidate when needed.

any thoughts?

see jackalope/jackalope#185

@dantleech i had a look at updating the PHPCR ODM QueryBuilder .. but I think there is now a big fundamental question .. either we now force people to first call from()/nodeType()(/join*()) or we must delay a lot to the end. i think i prefer the former over the later, simply because it will make validation a lot simpler and we can report incorrect selector names used in any following method.

furthermore I am wonder how we will properly handle joins eventually .. seems like several methods might need to get the ability to specify a selector.

Right now things are inconsistent if a NodeName field receives an illegal character (one of /, [, ], :, | or *). For example, if a "/" is supplied, we get a 404 from the repository since PHPCR-ODM treats it like a path character, while if a ":" is supplied we will get an illegal character exception from the repository.

It seems there are two options for handling these:

• Throw an exception if an illegal character is supplied
• Allow all characters, but escape them prior to persisting

For the latter, I wrote some code for UnitOfWork that enables the use of any of those characters in a NodeName field by encoding them before writing to the repository, and decoding upon retrieval. However I am not sure that is a direction the project wants to go in; Jackrabbit has some methods for doing this as well, but I am not sure what the best practice is.

The code works by keeping a mapping of raw node names to actual node names (e.g. "Example/Node" becomes "Example%2FNode"). It's not particularly complex, and seems to handle moving/reordering well, but I am sure there are edge cases I have not looked at.

If that IS something desirable, I could work on building out tests and investigate the edge cases. Otherwise maybe we could just throw an exception or something at the Doctrine level if an illegal character is provided, rather than passing it on to the repository?

For what its worth, it's a relevant issue for me because I deal with a lot of content that has phrases like "1/2" or "1/10" and that sort of thing. The obvious workaround is to slug the name and use that as the NodeName, but I wanted to see if I could make it work natively.

To allow event listeners to manipulate data the UnitOfWork needs a method to recompute the change set.

I might do a PR myself but it might take a couple of weeks.

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

we should have a little release script that helps us not forget to do this in the future. should we fix the 1.0.0 tag? or do a 1.0.1 tag just for this? or wait a moment to see if other things come before we do 1.0.1?

Hi,

Im getting this error:

  Problem 1
    - Installation request for jackalope/jackalope-doctrine-dbal dev-master@dev -> satisfiable by jackalope/jackalope-doctrine-dbal[dev-master].
    - Conclusion: don't install phpcr/phpcr-utils 1.0-beta5
    - doctrine/phpcr-odm 1.0.0 requires phpcr/phpcr-utils ~1.0.0 -> satisfiable by phpcr/phpcr-utils[1.0-beta1, 1.0-beta2, 1.0-beta3, 1.0-beta4, 1.0-beta5, 1.0.0, 1.0.0-RC1, 1.0.0-RC2, 1.0.0-beta10, 1.0.0-beta11, 1.0.0-beta12, 1.0.0-beta13, 1.0.0-beta14, 1.0.0-beta6, 1.0.0-beta7, 1.0.0-beta8, 1.0.0-beta9].
    - doctrine/phpcr-odm 1.0.1 requires phpcr/phpcr-utils ~1.0.0 -> satisfiable by phpcr/phpcr-utils[1.0-beta1, 1.0-beta2, 1.0-beta3, 1.0-beta4, 1.0-beta5, 1.0.0, 1.0.0-RC1, 1.0.0-RC2, 1.0.0-beta10, 1.0.0-beta11, 1.0.0-beta12, 1.0.0-beta13, 1.0.0-beta14, 1.0.0-beta6, 1.0.0-beta7, 1.0.0-beta8, 1.0.0-beta9].
    - doctrine/phpcr-odm 1.0.x-dev requires phpcr/phpcr-utils ~1.0.0 -> satisfiable by phpcr/phpcr-utils[1.0-beta1, 1.0-beta2, 1.0-beta3, 1.0-beta4, 1.0-beta5, 1.0.0, 1.0.0-RC1, 1.0.0-RC2, 1.0.0-beta10, 1.0.0-beta11, 1.0.0-beta12, 1.0.0-beta13, 1.0.0-beta14, 1.0.0-beta6, 1.0.0-beta7, 1.0.0-beta8, 1.0.0-beta9].
    - doctrine/phpcr-odm 1.0.0-RC1 requires phpcr/phpcr-utils ~1.0.0-RC1 -> satisfiable by phpcr/phpcr-utils[1.0.0, 1.0.0-RC1, 1.0.0-RC2].
    - doctrine/phpcr-odm 1.0.0-RC2 requires phpcr/phpcr-utils ~1.0.0-RC1 -> satisfiable by phpcr/phpcr-utils[1.0.0, 1.0.0-RC1, 1.0.0-RC2].
    - doctrine/phpcr-odm 1.0.0-RC3 requires phpcr/phpcr-utils ~1.0.0-RC1 -> satisfiable by phpcr/phpcr-utils[1.0.0, 1.0.0-RC1, 1.0.0-RC2].
    - doctrine/phpcr-odm 1.0.0-RC4 requires phpcr/phpcr-utils ~1.0.0-RC1 -> satisfiable by phpcr/phpcr-utils[1.0.0, 1.0.0-RC1, 1.0.0-RC2].
    - doctrine/phpcr-odm 1.0.0-RC5 requires phpcr/phpcr-utils ~1.0.0-RC1 -> satisfiable by phpcr/phpcr-utils[1.0.0, 1.0.0-RC1, 1.0.0-RC2].
    - doctrine/phpcr-odm 1.0.0-alpha1 requires phpcr/phpcr-utils ~1.0.0-beta6 -> satisfiable by phpcr/phpcr-utils[1.0.0, 1.0.0-RC1, 1.0.0-RC2, 1.0.0-beta10, 1.0.0-beta11, 1.0.0-beta12, 1.0.0-beta13, 1.0.0-beta14, 1.0.0-beta6, 1.0.0-beta7, 1.0.0-beta8, 1.0.0-beta9].
    - doctrine/phpcr-odm 1.0.0-alpha2 requires phpcr/phpcr-utils ~1.0.0-beta6 -> satisfiable by phpcr/phpcr-utils[1.0.0, 1.0.0-RC1, 1.0.0-RC2, 1.0.0-beta10, 1.0.0-beta11, 1.0.0-beta12, 1.0.0-beta13, 1.0.0-beta14, 1.0.0-beta6, 1.0.0-beta7, 1.0.0-beta8, 1.0.0-beta9].
    - doctrine/phpcr-odm 1.0.0-beta1 requires phpcr/phpcr-utils ~1.0.0-beta6 -> satisfiable by phpcr/phpcr-utils[1.0.0, 1.0.0-RC1, 1.0.0-RC2, 1.0.0-beta10, 1.0.0-beta11, 1.0.0-beta12, 1.0.0-beta13, 1.0.0-beta14, 1.0.0-beta6, 1.0.0-beta7, 1.0.0-beta8, 1.0.0-beta9].
    - doctrine/phpcr-odm 1.0.0-beta2 requires phpcr/phpcr-utils ~1.0.0-beta6 -> satisfiable by phpcr/phpcr-utils[1.0.0, 1.0.0-RC1, 1.0.0-RC2, 1.0.0-beta10, 1.0.0-beta11, 1.0.0-beta12, 1.0.0-beta13, 1.0.0-beta14, 1.0.0-beta6, 1.0.0-beta7, 1.0.0-beta8, 1.0.0-beta9].
    - doctrine/phpcr-odm 1.0.0-beta3 requires phpcr/phpcr-utils ~1.0.0-beta6 -> satisfiable by phpcr/phpcr-utils[1.0.0, 1.0.0-RC1, 1.0.0-RC2, 1.0.0-beta10, 1.0.0-beta11, 1.0.0-beta12, 1.0.0-beta13, 1.0.0-beta14, 1.0.0-beta6, 1.0.0-beta7, 1.0.0-beta8, 1.0.0-beta9].
    - doctrine/phpcr-odm 1.0.0-beta4 requires phpcr/phpcr-utils ~1.0.0-beta6 -> satisfiable by phpcr/phpcr-utils[1.0.0, 1.0.0-RC1, 1.0.0-RC2, 1.0.0-beta10, 1.0.0-beta11, 1.0.0-beta12, 1.0.0-beta13, 1.0.0-beta14, 1.0.0-beta6, 1.0.0-beta7, 1.0.0-beta8, 1.0.0-beta9].
    - doctrine/phpcr-odm 1.0.0-beta5 requires phpcr/phpcr-utils ~1.0.0-beta6 -> satisfiable by phpcr/phpcr-utils[1.0.0, 1.0.0-RC1, 1.0.0-RC2, 1.0.0-beta10, 1.0.0-beta11, 1.0.0-beta12, 1.0.0-beta13, 1.0.0-beta14, 1.0.0-beta6, 1.0.0-beta7, 1.0.0-beta8, 1.0.0-beta9].
    - Can only install one of: phpcr/phpcr-utils[1.1.0-RC1, 1.0-beta1].
    - Can only install one of: phpcr/phpcr-utils[1.1.0-RC1, 1.0-beta2].
    - Can only install one of: phpcr/phpcr-utils[1.1.0-RC1, 1.0-beta3].
    - Can only install one of: phpcr/phpcr-utils[1.1.0-RC1, 1.0-beta4].
    - Can only install one of: phpcr/phpcr-utils[1.1.0-RC1, 1.0.0].
    - Can only install one of: phpcr/phpcr-utils[1.1.0-RC1, 1.0.0-RC1].
    - Can only install one of: phpcr/phpcr-utils[1.1.0-RC1, 1.0.0-RC2].
    - Can only install one of: phpcr/phpcr-utils[1.1.0-RC1, 1.0.0-beta10].
    - Can only install one of: phpcr/phpcr-utils[1.1.0-RC1, 1.0.0-beta11].
    - Can only install one of: phpcr/phpcr-utils[1.1.0-RC1, 1.0.0-beta12].
    - Can only install one of: phpcr/phpcr-utils[1.1.0-RC1, 1.0.0-beta13].
    - Can only install one of: phpcr/phpcr-utils[1.1.0-RC1, 1.0.0-beta14].
    - Can only install one of: phpcr/phpcr-utils[1.1.0-RC1, 1.0.0-beta6].
    - Can only install one of: phpcr/phpcr-utils[1.1.0-RC1, 1.0.0-beta7].
    - Can only install one of: phpcr/phpcr-utils[1.1.0-RC1, 1.0.0-beta8].
    - Can only install one of: phpcr/phpcr-utils[1.1.0-RC1, 1.0.0-beta9].
    - jackalope/jackalope-doctrine-dbal dev-master requires phpcr/phpcr-utils ~1.1.0 -> satisfiable by phpcr/phpcr-utils[1.1.0-RC1, 1.1.x-dev].
    - Conclusion: don't install phpcr/phpcr-utils 1.1.x-dev|install phpcr/phpcr-utils 1.0-beta5
    - Installation request for doctrine/phpcr-odm 1.0.* -> satisfiable by doctrine/phpcr-odm[1.0.0, 1.0.0-RC1, 1.0.0-RC2, 1.0.0-RC3, 1.0.0-RC4, 1.0.0-RC5, 1.0.0-alpha1, 1.0.0-alpha2, 1.0.0-beta1, 1.0.0-beta2, 1.0.0-beta3, 1.0.0-beta4, 1.0.0-beta5, 1.0.1, 1.0.x-dev].

with this configuration:

{
    "name": "symfony/framework-standard-edition",
    "license": "MIT",
    "type": "project",
    "description": "The \"Symfony Standard Edition\" distribution",
    "autoload": {
        "psr-0": { "": "src/" }
    },
    "minimum-stability": "dev",
    "require": {
        "php": ">=5.3.3",
        "symfony/symfony": "~2.4",
        "doctrine/orm": "~2.2,>=2.2.3",
        "doctrine/doctrine-bundle": "~1.2",
        "twig/extensions": "~1.0",
        "symfony/assetic-bundle": "~2.3",
        "symfony/swiftmailer-bundle": "~2.3",
        "symfony/monolog-bundle": "~2.4",
        "sensio/distribution-bundle": "~2.3",
        "sensio/framework-extra-bundle": "~3.0",
        "sensio/generator-bundle": "~2.3",
        "incenteev/composer-parameter-handler": "~2.0",
         "symfony-cmf/symfony-cmf": "1.0.*",
                        "jackalope/jackalope-doctrine-dbal": "dev-master@dev",
    "doctrine/phpcr-bundle": "1.0.*",
    "doctrine/phpcr-odm": "1.0.*",
        "phpcr/phpcr-utils": "~1.1.0@dev"
    },
    "scripts": {
        "post-install-cmd": [
            "Incenteev\\ParameterHandler\\ScriptHandler::buildParameters",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile"
        ],
        "post-update-cmd": [
            "Incenteev\\ParameterHandler\\ScriptHandler::buildParameters",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile"
        ]
    },
    "config": {
        "bin-dir": "bin"
    },
    "extra": {
        "symfony-app-dir": "app",
        "symfony-web-dir": "web",
        "incenteev-parameters": {
            "file": "app/config/parameters.yml"
        },
        "branch-alias": {
            "dev-master": "2.4-dev"
        }
    }
}