follow up of https://jira.liip.ch/browse/JACK-11

this test fails (even with the jsop jackrabbit transport) phpcr/phpcr-api-tests@a512c88

i wonder if we should, instead of calculating a changeset, just record all operations with the transport. but that would be a rather drastic change and could lead to quite some overhead when the phpcr user is not doing things straightforward.

btw #99 is an internal state issue, i think it is not related to this problem here

I was trying to run a script that imports data into jackrabbit. After running for a very long time, at some point it died due to memory exhaustion.

The stack trace looked a bit suspicious, since there's 1200 calls to the same functions over and over. It looks like a potential recursion bug.

The tail of the stack trace:

967.7610  990701032 1165. Jackalope\Node->getIdentifier() /Users/me/project/vendor/jackalope/src/Jackalope/ObjectManager.php:1518
967.7610  990701032 1166. Jackalope\Item->checkState() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:580
967.7611  990701032 1167. Jackalope\Node->refresh() /Users/me/project/vendor/jackalope/src/Jackalope/Item.php:522
967.8066  996698872 1168. Jackalope\ObjectManager->purgeDisappearedNode() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:986
967.8067  996698872 1169. Jackalope\Node->getIdentifier() /Users/me/project/vendor/jackalope/src/Jackalope/ObjectManager.php:1518
967.8067  996698872 1170. Jackalope\Item->checkState() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:580
967.8067  996698872 1171. Jackalope\Node->refresh() /Users/me/project/vendor/jackalope/src/Jackalope/Item.php:522
967.8555 1002716904 1172. Jackalope\ObjectManager->purgeDisappearedNode() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:986
967.8556 1002716904 1173. Jackalope\Node->getIdentifier() /Users/me/project/vendor/jackalope/src/Jackalope/ObjectManager.php:1518
967.8556 1002716904 1174. Jackalope\Item->checkState() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:580
967.8556 1002716904 1175. Jackalope\Node->refresh() /Users/me/project/vendor/jackalope/src/Jackalope/Item.php:522
967.9026 1008754872 1176. Jackalope\ObjectManager->purgeDisappearedNode() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:986
967.9026 1008754872 1177. Jackalope\Node->getIdentifier() /Users/me/project/vendor/jackalope/src/Jackalope/ObjectManager.php:1518
967.9026 1008754872 1178. Jackalope\Item->checkState() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:580
967.9027 1008754872 1179. Jackalope\Node->refresh() /Users/me/project/vendor/jackalope/src/Jackalope/Item.php:522
967.9517 1014813064 1180. Jackalope\ObjectManager->purgeDisappearedNode() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:986
967.9518 1014813064 1181. Jackalope\Node->getIdentifier() /Users/me/project/vendor/jackalope/src/Jackalope/ObjectManager.php:1518
967.9518 1014813064 1182. Jackalope\Item->checkState() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:580
967.9518 1014813064 1183. Jackalope\Node->refresh() /Users/me/project/vendor/jackalope/src/Jackalope/Item.php:522
967.9997 1020891704 1184. Jackalope\ObjectManager->purgeDisappearedNode() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:986
967.9998 1020891704 1185. Jackalope\Node->getIdentifier() /Users/me/project/vendor/jackalope/src/Jackalope/ObjectManager.php:1518
967.9998 1020891704 1186. Jackalope\Item->checkState() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:580
967.9998 1020891704 1187. Jackalope\Node->refresh() /Users/me/project/vendor/jackalope/src/Jackalope/Item.php:522
968.0897 1026990200 1188. Jackalope\ObjectManager->purgeDisappearedNode() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:986
968.0898 1026990200 1189. Jackalope\Node->getIdentifier() /Users/me/project/vendor/jackalope/src/Jackalope/ObjectManager.php:1518
968.0903 1027514048 1190. Jackalope\Item->checkState() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:580
968.0903 1027514048 1191. Jackalope\Node->refresh() /Users/me/project/vendor/jackalope/src/Jackalope/Item.php:522
968.1374 1033632624 1192. Jackalope\ObjectManager->purgeDisappearedNode() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:986
968.1375 1033632624 1193. Jackalope\Node->getIdentifier() /Users/me/project/vendor/jackalope/src/Jackalope/ObjectManager.php:1518
968.1375 1033632624 1194. Jackalope\Item->checkState() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:580
968.1375 1033632624 1195. Jackalope\Node->refresh() /Users/me/project/vendor/jackalope/src/Jackalope/Item.php:522
968.1869 1039771320 1196. Jackalope\ObjectManager->purgeDisappearedNode() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:986
968.1870 1039771320 1197. Jackalope\Node->getIdentifier() /Users/me/project/vendor/jackalope/src/Jackalope/ObjectManager.php:1518
968.1870 1039771320 1198. Jackalope\Item->checkState() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:580
968.1870 1039771320 1199. Jackalope\Node->refresh() /Users/me/project/vendor/jackalope/src/Jackalope/Item.php:522
968.2343 1045930232 1200. Jackalope\ObjectManager->purgeDisappearedNode() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:986
968.2343 1045930232 1201. Jackalope\Node->getIdentifier() /Users/me/project/vendor/jackalope/src/Jackalope/ObjectManager.php:1518
968.2343 1045930232 1202. Jackalope\Item->checkState() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:580
968.2344 1045930232 1203. Jackalope\Node->refresh() /Users/me/project/vendor/jackalope/src/Jackalope/Item.php:522
968.3044 1052109176 1204. Jackalope\ObjectManager->purgeDisappearedNode() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:986
968.3045 1052109176 1205. Jackalope\Node->getIdentifier() /Users/me/project/vendor/jackalope/src/Jackalope/ObjectManager.php:1518
968.3045 1052109176 1206. Jackalope\Item->checkState() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:580
968.3045 1052109176 1207. Jackalope\Node->refresh() /Users/me/project/vendor/jackalope/src/Jackalope/Item.php:522
968.3046 1052109512 1208. Jackalope\Transport\Jackrabbit\Client->getNode() /Users/me/project/vendor/jackalope/src/Jackalope/Node.php:982

Contact me for more details.

setOffset is doing weird things with there is no limit set.

With the current implementation, setting an offset and no limit has no effect (returns the same nodes as if there was no offset specified).

I found this:

https://github.com/jackalope/jackalope/blob/master/src/Jackalope/Transport/Jackrabbit/Client.php#L686

if (null !== $limit || null !== $limit) {

I changed the second null !== $limit for null !== $offset, and whit that change, the behaviour is:

• It returns correctly (total number of results) - offset nodes.
• The first node is the same as if you don't apply offset at all.

I am experiencied this while implementing findBy of the ODM using QOM, I arrived here, but no clue on how to continue. I can provide code to test this (broken tests for that findBy method and the method itself).

In the ObjectManager there is no need to test for the transport being an instance of TransactionInterface in each transaction related functions.

Indeed the test is already done in Workspace::getTransactionManager

this will be a failing test as soon as somebody updates the phpcr-api-tests. see

phpcr/phpcr-api-tests#48

the existing issues (feature epics and bugs) are at https://jira.liip.ch/browse/JACK
we should eventually migrate them here, use the link to jira for now.

implement the Read part of the NodeType

there are unit tests, but we miss api tests and probably some finishing work

• complete the api tests
• implement the primary node feature that allows to define some sort of "default" child for a node.
• implement templates
• type exists exception
• InvalidNodeTypeDefinitionException

getting and setting version labels could be used to build simple workflows.

the methods are

VersionHistory::addVersionLabel
VersionHistory::getVersionByLabel
VersionHistory::getVersionLabels
VersionHistory::hasVersionLabel
VersionHistory::removeVersionLabel

when fixed, also update Repository::jackalopeNotImplemented

There were 2 errors:

1. PHPCR\Tests\Connecting\RepositoryDescriptorsTest::testDescriptorKeys
   PHPCR\RepositoryException: Unexpected error:
   CURL Error:
   Response (HTTP 401): REPORT array (
   'http://localhost:8080/server/' => 'http://localhost:8080/server/',
   )

/Users/lsmith/htdocs/symfony-standard/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Transport/Jackrabbit/Request.php:468
/Users/lsmith/htdocs/symfony-standard/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Transport/Jackrabbit/Request.php:392
/Users/lsmith/htdocs/symfony-standard/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Transport/Jackrabbit/Request.php:287
/Users/lsmith/htdocs/symfony-standard/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Transport/Jackrabbit/Request.php:481
/Users/lsmith/htdocs/symfony-standard/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Transport/Jackrabbit/Client.php:283
/Users/lsmith/htdocs/symfony-standard/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Repository.php:164
/Users/lsmith/htdocs/symfony-standard/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Repository.php:119
/Users/lsmith/htdocs/symfony-standard/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/tests/phpcr-api/tests/04_Connecting/RepositoryDescriptorsTest.php:33

2. PHPCR\Tests\Connecting\RepositoryDescriptorsTest::testDescription
   PHPCR\RepositoryException: Unexpected error:
   CURL Error:
   Response (HTTP 401): REPORT array (
   'http://localhost:8080/server/' => 'http://localhost:8080/server/',
   )

/Users/lsmith/htdocs/symfony-standard/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Transport/Jackrabbit/Request.php:468
/Users/lsmith/htdocs/symfony-standard/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Transport/Jackrabbit/Request.php:392
/Users/lsmith/htdocs/symfony-standard/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Transport/Jackrabbit/Request.php:287
/Users/lsmith/htdocs/symfony-standard/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Transport/Jackrabbit/Request.php:481
/Users/lsmith/htdocs/symfony-standard/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Transport/Jackrabbit/Client.php:283
/Users/lsmith/htdocs/symfony-standard/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Repository.php:153
/Users/lsmith/htdocs/symfony-standard/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/tests/phpcr-api/tests/04_Connecting/RepositoryDescriptorsTest.php:46

with the jackrabbit backend, this halfways works but not fully. there are some cases to be handled inside jackalope to manage backend same-name siblings.

use https://github.com/sixty-nine/Jackrabbit-startup-script
plus the scripts liip opsy team did to monitor and restart

maybe use this to generate packages for various distributions:
https://github.com/liip/packaging

we only have support to handle namespaces and add namespaces, but not to remap them locally in a session (mostly useful in case of namespace prefix collisions).
the session remapping is probably tricky as we need to rewrite all the paths for the storage layer.

basically we need to str_replace the local namespace with the backend namespace and back whenever we talk to the backend. or use the backend namespace internally and replace on all requests and results, but that is probably even more difficult.

when fixed, also update Repository::jackalopeNotImplemented

as a long (or middle) term goal we should thinking about switching to
the diff/patch format, which could boost write performance and make it
easier. Jackalope just replays on .save() what was done before, so one
would just have to record that logfile and replay it.

eg.

Node f = root.addNode("foo");
f.addNode("a");
f.addNode("b");
Node c = f.addNode("c");
c.setProperty("foo","bar");
f.orderBefore("a","c");
f.orderBefore("b","a");
c.remove();
f.addNode("c");
s.save();*

ends up in

+/foo : {"jcr:primaryType":"nt:unstructured"}
+/foo[4]/a : {"jcr:primaryType":"nt:unstructured"}
+/foo[4]/b : {"jcr:primaryType":"nt:unstructured"}
+/foo[4]/c : {"jcr:primaryType":"nt:unstructured"}
^/foo[4]/c/foo : "bar"
> /foo[4]/a : c#before
> /foo[4]/b : a#before
-/foo[4]/c :
+/foo[4]/c : {"jcr:primaryType":"nt:unstructured"}

This needs quite some changes/additions in jackalope (we have to call
the transport on every write operations, so that it can record the
history, if needed and not only on save like we do now. Or build up our
own log, which the transport can read on save), but should simplify
things, afaics now

doctrine/phpcr-odm#122

look at the TODO comments in this test: phpcr/phpcr-api-tests@ab2e89d

uncomment the check and fix the issue in jackalope

Following instructions in tests/README.md results in phpunit help/syntax message dumped to stdout after running command sequence "cd tests; phpunit;" at the command line. The correct setup or command-line parameters for running the tests should be reflected on this README to make running tests accessible to new users.

https://issues.apache.org/jira/browse/JCR-3005 is done, but will likely require some changes to our davex client.

@chregu already started on this in https://github.com/jackalope/jackalope/tree/jackrabbit_multiget_from_2_4

Should throw InvalidQueryException with message to use getQOMFactory when using JCR_JQOM

follow-up of #110

need to build getSupportedQueryLanguages into Transport\QueryInterface. at the moment QueryManager::getSupportedQueryLanguages is not telling the thruth anyways, it has to return all languages we support. i guess we should redirect getSupportedQueryLanguages to transport and call it in createQuery to check if we should create that type of query.

the Transport\QueryInterface has a TODO about getSupportedQueryLanguages already btw

Since Jackrabbit allows me to add files with "&" character in it I guess Jackalope would also have to allow me to read those paths.

Exception Message: Path is not well-formed or contains invalid characters: /edu/jhu/pha/www/einstein/stuff/einstein&music.pdf

https://github.com/phpcr/phpcr/blob/master/src/PHPCR/Query/QueryInterface.php#L222
https://github.com/phpcr/phpcr/blob/master/src/PHPCR/Query/QueryManagerInterface.php#L86

for how the data is stored, look at jackrabbit for inspiration

we should check the code coverage and improve it with either more phpcr-api tests or unit or functional tests in jackalope.

for example, the jackrabbit transport has two methods that read a stream and until #44 one closed the stream as it should but the other left it open.

potentially even allowing to send a mixed list of UUID's and paths .. this would help in the ODM layer to de-reference multiple MANY_TO_ONE references:
doctrine/phpcr-odm@00cf981

For Jackrabbit we would need to first add support for this inside the Davex API

cc @chregu

There are a couple of export tests failing on Doctrine DBAL because the custom namespaces are not properly exported:

PHPCR\Tests\Export\ExportRepositoryContentTest::testExportDocumentView
DOMDocument::loadXML(): Namespace prefix test on namespacedNode is not defined in Entity, line: 2

/projects/PHPCR/jackalope/tests/phpcr-api/tests/07_Export/ExportRepositoryContentTest.php:106

I traced that to the namespace prefix registrations not being in the database in the first place. Because the test fixtures are not going through a real import process, but are converted into PHPUnit DB fixtures by the generate_doctrine_dbal_fixture.php script, shall we just add support for namespaces in this script?

Damien

Adding a new mixin type to a node that already has another mixin type fails. This is either a special case of mixin or maybe even a general issue with multivalue properties.

see 10_Writing/NodeTypeAssignmentTest::testAddMixinTwice

on the update, jackalope transport sends this:

PROPPATCH /server/tests/jcr:root/tests_write_nodetype/testAddMixinTwice HTTP/1.1
Authorization: Basic YWRtaW46YWRtaW4=
Host: localhost:8080
Accept: */*
Depth: 0
Content-Type: text/xml; charset=utf-8
User-Agent: jackalope-php/1.0
TransactionId: <opaquelocktoken:9e96b564-5b32-47b2-ac96-8bbdc894d8c7>
Content-Length: 370

<?xml version="1.0" encoding="UTF-8"?><D:propertyupdate xmlns:D="DAV:"><D:set><D:prop><dcr:mixinnodetypes xmlns:dcr="http://www.day.com/jcr/webdav/1.0"><dcr:nodetype><dcr:nodetypename>mix:referenceable</dcr:nodetypename></dcr:nodetype><dcr:nodetype><dcr:nodetypename>mix:mimeType</dcr:nodetypename></dcr:nodetype></dcr:mixinnodetypes></D:prop></D:set></D:propertyupdate>

while jackrabbit uses the diff format:

POST /server/tests/jcr%3aroot/ HTTP/1.1
Authorization: Basic YWRtaW46YWRtaW4=
User-Agent: Jakarta Commons-HttpClient/3.0
Host: localhost:8080
Content-Length: 717
Content-Type: multipart/form-data; boundary=m4KJBTKajpqZ-F6H2rWTQLaUSNL9qY2jm

--m4KJBTKajpqZ-F6H2rWTQLaUSNL9qY2jm
Content-Disposition: form-data; name="/tests_write_nodetype/testAddMixinTwice/jcr:mixinTypes"
Content-Type: jcr-value/name; charset=UTF-8
Content-Transfer-Encoding: 8bit

mix:referenceable
--m4KJBTKajpqZ-F6H2rWTQLaUSNL9qY2jm
Content-Disposition: form-data; name="/tests_write_nodetype/testAddMixinTwice/jcr:mixinTypes"
Content-Type: jcr-value/name; charset=UTF-8
Content-Transfer-Encoding: 8bit

mix:mimeType
--m4KJBTKajpqZ-F6H2rWTQLaUSNL9qY2jm
Content-Disposition: form-data; name=":diff"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

^/tests_write_nodetype/testAddMixinTwice/jcr:mixinTypes : []
--m4KJBTKajpqZ-F6H2rWTQLaUSNL9qY2jm--

we have to figure out whether there is some way to specify the change in the xml format correctly, or we have to implement the diff stuff.

1. test if this is mixin specific or relevant for all multivalue properties
2. see if the xml format can update multivalue or if we need to do the diff
3. implement solution

Implement missing features in VersionManager::restore (see TODOs around)
https://github.com/jackalope/jackalope/blob/master/src/Jackalope/Version/VersionManager.php#L160

• implement restoring a list of versions
• implement restoring a version to a specified path

now that we have composer and removed the .gitmodules, all our setup instruction in the README files are wrong

jackalope-jackrabbit, jackalope-doctrine-dbal, phpcr-odm, https://github.com/symfony-cmf/symfony-cmf-docs/blob/master/tutorials/installing-configuring-doctrine-phpcr-odm.rst

/cc @cordoval, @lsmith77

for the jackrabbit backend, this first needs the ACL over Davex implemented: https://issues.apache.org/jira/browse/JCR-2003

This means implementing the interfaces of https://github.com/phpcr/phpcr/tree/master/src/PHPCR/Security

The JCR specification chapter is http://www.day.com/specs/jcr/2.0/16_Access_Control_Management.html

the retention policy part needs some implementation specific things to do it
http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/retention/package-summary.html

from what i guess, this is about whether nodes are cached in an open session or when to stop caching them to let garbage collection free up some memory. no clue what the hold part is doing in this.

implement the methods to merge versions

when fixed, also update Repository::jackalopeNotImplemented

look at the todos in #105: create unit tests for ImportExport::escapeXmlName and ImportExport::unescapeXmlName, fix bugs and add data to the phpcr-api-test documents and tests.

We should abstract getting the parent path into one method (maybe even in phpcr-utils) and remove any calls to dirname from jackalope, as this can fail on windows (see 2b6fdbd and grep for dirname in the code)

Session locks have been merged in #77. missing are lock tokens and locks that survive session logout.

when fixed, also update Repository::jackalopeNotImplemented

the travis-ci guys said that either a JVM is already available or if not they can add it.
would also be nice to get the DBAL one running on there.

there seems to be an issue with fixture generation.

see #39 https://github.com/jackalope/jackalope/pull/39/files#r262394

the exception we get when the credentials are invalid is very confusing. it should be improved to throw a LoginException and say something like "the backend did not accept our credentials"

PHPCR\RepositoryException: Unexpected error:
CURL Error:
Response (HTTP 401): PROPFIND array (
'http://127.0.0.1:8080/server/tests' => 'http://127.0.0.1:8080/server/tests',
)

/home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Transport/Jackrabbit/Request.php:473
/home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Transport/Jackrabbit/Request.php:397
/home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Transport/Jackrabbit/Request.php:289
/home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Transport/Jackrabbit/Request.php:486
/home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Transport/Jackrabbit/Client.php:253
/home/david/liip/symfony-cmf/cmf-sandbox/vendor/symfony-cmf/vendor/doctrine-phpcr-odm/lib/vendor/jackalope/src/Jackalope/Repository.php:99

• do a performance analysis
• identify main bottlenecks
• improve the bottlenecks
• some suspected problems are tagged with //OPTIMIZE
• look for places where we could use getNodes or getNodesByIdentifier, instead of looping

ideas:

• have a flexible cache object injected into ObjectManager. write one that uses memcache instead of the array to persist the cache over requests (will require some cache outdate logic, plus changes to make sure permissions are respected and local modifications don't leak into other sessions)
• play with the depth parameter to retrieve more than one node in one request - but if we do that stupidly, we might slow everything down as we could retrieve way too many nodes. provide a way for hints, or learning, or whatever.
• have a clever iterator for Node::getNodes that fetches a couple of nodes at a time to scale with large number of children (see FIXME in #95)

implement importing repository content from xml. (document view and system view)

this will work with the newest jackrabbit versions:
https://issues.apache.org/jira/browse/JCR-3144

jackalope itself should check for valid namespace prefixes.

jackalope-doctrine-dbal fails during save with

Notice: Undefined index: phpcr_locale in .../jackalope-doctrine-dbal/src/Jackalope/Transport/DoctrineDBAL/Client.php line 440

jackalope-jackrabbit fails on save too, while talking to the backend

Sending this message without having "phpcr" registered as a namespace:
string(625) "<sv:node xmlns:sv="http://www.jcp.org/jcr/sv/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" sv:name="user"><sv:property sv:name="jcr:primaryType" sv:type="Name">sv:valuent:unstructured/sv:value/sv:property<sv:property sv:name="username" sv:type="String">sv:value/sv:value/sv:property<sv:property sv:name="numbers" sv:type="Long">sv:value3/sv:valuesv:value1/sv:valuesv:value2/sv:value/sv:property<sv:property sv:name="phpcr:class" sv:type="String">sv:value/sv:value/sv:property/sv:node"

Leads to this is the response:
string(317) "<D:error xmlns:D="DAV:"><dcr:exception xmlns:dcr="http://www.day.com/jcr/webdav/1.0">dcr:classjavax.jcr.InvalidSerializedDataException/dcr:classdcr:messageillegal property name: {http://www.jcp.org/jcr/sv/1.0}property/dcr:message/dcr:exception/D:error"

And finally this exception:
PHPCR\InvalidSerializedDataException: HTTP 400: illegal property name: {http://www.jcp.org/jcr/sv/1.0}property

i don't have time to isolate this as i managed to fix this via a work around. the issue can also be inside the ODM.

essentially in a single session i have created a parent node with new children via the ODM and then try to remove the parent node i end up with an issue inside Jackalope where it fails because it decides it cannot remove a node because its already marked as deleted.

Essentially it seems like remove() is being called multiple times for the same node. Again the issue could be in the ODM, but I suspect its in Jackalope.

The current work around I did was to use Jackalope's session directly and first remove the children and then the parent. However I just tried only removing the parent via Jackalope and that seemed to work .. so maybe its an ODM issue after all. Maybe caused by cascading the delete .. which is probably not necessary?

JCR defines an observation interface. In php we would have to register all observers on every request, which is not realistic and potentially a huge performance issue. To work around that, we could implement an javax.jcr.observation.EventListener (in Java) that can be configured for events and calls an URL or php cli to let php developers react to the event.

http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/index.html > javax.jcr.observation

For the pure php backend, the same configuration could be used to launch events based on repository operations.

Fully implementing the javax.jcr.observation classes in PHPCR is probably not going to work, as we do not have a long running server instance. So the listener would have to be instantiated first and be able to bootstrap itselves and whatnot. Nonetheless ObservationManager.getEventJournal could be useful.
We could also re-use the EventListener interface to allow defined communication between the storage backend and the event listener.

the spi uses a poll model. that is, the server stores all registered events and the client can do a poll for events. we should build on this model.

It would be very useful for there to be release versions that users can develop against. Also publishing on packagist.org would be a major win.

This would have several benefits:

1. easier to deal with different groups of maintainers
2. separate release cycles
3. easier to handle CI setup
4. clearer dependencies
5. better visibility for the different transports

The draw back would be one more dependency for users to configure.

In terms of work we would best do a subtree split of the current 2 transports (we could do the same with @chirimoya's fork).
The phpcr-api-tests would then have to be setup to run on the transport repositories. The jackalope unit tests would then likely need to be split, some remaining with Jackalope and any transport specific ones moved to the given transport.

SQL2 and QOM are required by the JCR spec, with such a converter implementations would only need to implement QOM and could rely on Jackalope to convert SQL2 to QOM queries.

pseudocode

$node = addNode
$session->save
$session->refresh
$node->addNode
$session->save

=> second node is not added. the internal state seems to get messed up.