This PR expands reference in the PHPCR dump to change:

./app/console doctrine:phpcr:dump /cms/chronology --props 
  2011-01-20:
    - references = Array(    [0] => 78b6f31b-f72a-4514-8f9d-b6e4a6786134    [1] => 896a3903-2614-4f8d-
8543-0758022aaa4d    [2] => 43d60...
    - phpcr:classparents = Array()
    - phpcr:class = DTL\TravelBundle\Document\ChronoDate

to

./app/console doctrine:phpcr:dump /cms/chronology --props --expand-references
  2011-01-20:
    - references = 
       - ref: /cms/content/DTLs Blog/aut-molestiae-rerum-eum-eius
       - ref: /cms/media/e6d2cab1959d05eeeec8ebe6bb3f1f3068e89f4e.jpeg
       - ref: /cms/media/49c33d6063f1ad0f3d4a3aa7d09b986c4ccddd02.jpeg
       - ref: /cms/media/34f453a6b65d58345e1ff639b5714da451698178.jpeg
    - phpcr:classparents = Array()
    - phpcr:class = DTL\TravelBundle\Document\ChronoDate

This is really good for debugging, not so sure on the name of the option however. I also wonder if we shouldn't list array properties in a similar way.

This option gives us a very quick and flexible solution for migrations:

./bin/phpcr phpcr:nodes:update --query="SELECT * FROM [nt:unstructured] WHERE ..." --apply-closure="function ($session, $node) { if (null !== $node->getProperty('url')) { $node->setProperty('linkType', 'externalUrl'); }"

What do people think?

I have added a shortcut for ->getQOMFactory(), ->qomf() which is more analogous to the ORM's ->expr() shortcut.

    $qb->orWhere($qb->qomf()->comparison(
        $qb->qomf()->propertyValue('blog'),
        QOMConstants::JCR_OPERATOR_EQUAL_TO,
        $qb->qomf()->literal('My Blog')
    ));

rather than:

            $qomf = $qb->getQOMFactory();
            $qb->orWhere($qomf->comparison(
                $qomf->propertyValue('blog'),
                Constants::JCR_OPERATOR_EQUAL_TO,
                $qomf->literal($options['blog_uuid'])
            ));

What do you think?

Do you think it would be correct to add a shortcut for the Constants aswell?

  $qb->qomf()->operator('equal_to'); // or
  $qb->constrants('operator_equal_to'); // or
  $qb->operator('equal_to');

CND data was not correctly parsed while using Windows OS. The issue was caused by the different line endings between the operating systems.

I came up with a fix and updated the unit tests to test both Windows and Unix line endings.

I've found some discrepancies inside the FileReader class, so it is updated as well.

This commit fixes: https://github.com/symfony-cmf/symfony-cmf-standard/issues/21

In the current version of the scanner, the scanner splits the string by spaces and then in a second pass it just gets the spaces in order to put the strings back together in the QueryConverter. This doesn't make much sense and can be very harmful to bigger queries. (as we found out even preg_match has a size limitation).

After this merge request it parses the strings in the query directly into one token which also simplifies the QueryConverter.

• This command updates multiple nodes in a workspace based on a given SQL query.

./bin/phpcr workspace:node:update "SELECT FROM nt:unstructred" --set-prop=foo=bar --add-mixin=some:mixin

Follows same options as node:touch. There is also room for adding a workspace:node:remove command for selectively removing nodes from a workspace.

Also some refactoring.

fixes jackalope/jackalope-doctrine-dbal#298

Even better will be to use rhumsaa/uuid library, imho (so I added it). openssl_random_pseudo_bytes function was failing on PHP 5.3.3.

Thus, this PR also fixes #120

This is an "enabling" improvement which allows me to use the parser to parse things like:

UPDATE [foo] SET foo = ['foo','bar',baz'];

Square brackets are delimiters in JCR-SQL2 (right?) so I think this is valid without compromise.

we should not create an instance of the phpcr_cli helper manually. i wonder why we even have both PhpcrHelper and PhpcrCliHelper - can we just merge the additional functionality into PhpcrHelper instead? /cc @dantleech

This adds a generic Qom to SQL1 Convertor like the SQL2 one to be used in jackalope-jackrabbit for letting the the QOM decide which SQL engine should be used

See also:

https://github.com/jackalope/jackalope/pull/115 https://github.com/jackalope/jackalope-jackrabbit/pull/17

This is just an proof of concept PR, so basically I propose to renmae the classes as follows:

./NodeMoveCommand.php
./NodeRemoveCommand.php
./NodeTouchCommand.php
./NodeTypeListCommand.php
./NodeTypeRegisterCommand.php
./WorkspaceCreateCommand.php
./WorkspaceDumpCommand.php
./WorkspaceExportCommand.php
./WorkspaceImportCommand.php
./WorkspaceListCommand.php
./WorkspacePurgeCommand.php
./WorkspaceQueryCommand.php

and that would then translate to the following command schema:

phpcr:workspace:purge
phpcr:workspace:import
phpcr:workspace:query
...
phpcr:node-type:register
...
phpcr:node:touch
...

Not sure if I have categorized things correctly, does dump,import|export etc belong in workspace?

CndParser hangs on buggy CND, only with PHP 7

$cnd = <<<EOT
la /*
EOT;

revert https://github.com/phpcr/phpcr-api-tests/commit/6ca175b8048fd492088022cf3e2188236fc34706 to see that the fix works.

e.g. it produces the following:

SELECT s FROM nt:unstructured WHERE i18n:de-changer = 11

Which is invalid JCR-SQL2 it should be:

SELECT s FROM nt:unstructured WHERE [i18n:de-changer] = 11

This causes problems with Jackrabbit, but not doctrine-dbal which doesn't care.

Note that this is also specifically a problem for PHPCRSH when we perform UPDATEs. Normally queries to Jackrabbit are passed directly - bypassing the phpcr-utils SQL2 generation.

In PHPCRSH however we parse the UPDATE (and implicitly the SELECT) which reveals this issue.

The following query cannot be parsed:

SELECT * FROM [nt:unstructured] AS a 
    INNER JOIN [nt:unstructured] AS b ON ISCHILDNODE(b,a) 
    INNER JOIN [nt:unstructured] AS c ON ISCHILDNODE(c,b);

we probably still have an issue with operator precedence for the NOT case.

how does the query builder distinguish NOT(a OR b) from (NOT a) OR b? afaik NOT a OR b precedence would make it (NOT a) or b.

see discussion in https://github.com/phpcr/phpcr-api-tests/pull/140/files#r20051310

/cc @dantleech

I'm not sure what the exact problem is with the following, but for example the query operators are not properly quoted (but fixing this does not make the CND valid):

<mix='http://www.jcp.org/jcr/mix/1.0'>
<nt='http://www.jcp.org/jcr/nt/1.0'>
[mix:menuItem] > nt:unstructured
orderable mixin query
- label (String)
mandatory jcr.operator.equal.to', 'jcr.operator.greater.than', 'jcr.operator.greater.than.or.equal.to', 'jcr.operator.less.than', 'jcr.operator.less.than.or.equal.to', 'jcr.operator.like', 'jcr.operator.not.equal.to
- path (String)
mandatory jcr.operator.equal.to', 'jcr.operator.greater.than', 'jcr.operator.greater.than.or.equal.to', 'jcr.operator.less.than', 'jcr.operator.less.than.or.equal.to', 'jcr.operator.like', 'jcr.operator.not.equal.to
+ nt:unstructured (mix:menuItem)