You can clone with
any transport layer should be easily configured to use this implementation for full text search as a replacement for whatever it natively provides. this way users will get easy access to a high performant full text search solution with additional capabilities like facetting that are not covered by PHPCR.
well this will make the php-only implementation again use a java product. but i guess still can make sense, devs are more familiar with solr, as are hosters.
and i guess someone could then also easily integrate Zend_Search_Lucene
@lsmith77 I will take a closer at the implementation to better unterstand how this could work together with https://github.com/ruflin/Elastica
essentially PHPCR provides a query syntax called SQL2 (this is essentially the string serialization of the QOM APi which defines queries as an object graph). you can find more details about it here:http://www.h2database.com/jcr/grammar.html
Note I dont think we necessarily need to support joins initially.
i think we should close this and keep the task at jackalope/jackalope-doctrine-dbal#14 - or close the other one, if we want to provide this on the transport agnostic jackalope level.
i think it makes more sense to do this transport agnostic as I see no benefit or simplification by doing it transport specific.