To enable ComplexPhraseQueryParser in Solr 1.4.0

1-) extract ComplexPhrase.zip and run 'mvn package'
2-) copy the ComplexPhrase/target/ComplexPhrase-1.0.jar to solrhome/lib directory
3-) register queryparser to solrhome/conf/solrconfig.xml by adding
<queryParser name="complexphrase" class="org.apache.solr.search.ComplexPhraseQParserPlugin" />
4-) enable it by appending &defType=complexphrase to search url.
5-) More permanent usage can be configured in solrconfig.xml
<requestHandler name="standard" class="solr.StandardRequestHandler" default="true">
<lst name="defaults">
<str name="defType">complexphrase</str>
</lst>
</requestHandler>

There is a fixed but forgotten bug in ComplexPhraseQuery at lucene-misc-2.9.1.jar.
This patch includes addition of a jar to trunk/lib directory.
This jar has the corrected version of ComplexPhraseQueryParser.
I couldn't include the corrected version of ComplexPhraseQueryParser in patch because it accesses a package-private field in Lucene's QueryParser.

solr-core maven artifact already contains AbstractSolrTestCase, so it is deleted from test source directory.

To enable ComplexPhraseQueryParser in Solr 1.4.0 - Revisited

Due to the reasons revealed here [1] this plugin should be loaded using the old way [2]

[1] http://search-lucene.com/m/E49gN1naPyh
[2] http://wiki.apache.org/solr/SolrPlugins#The_Old_Way

1-) extract ComplexPhrase.zip and run 'mvn package'
2-) unzip apache-solr-1.4.0.zip and copy ComplexPhrase/target/ComplexPhrase-1.0.jar to apache-solr-1.4.0/lib directory.
3-) create a new apache-solr-1.4.0\dist\apache-solr-1.4.1-dev.war (by running 'ant dist') and use it.

4-) register queryparser to solrhome/conf/solrconfig.xml by adding
<queryParser name="complexphrase" class="org.apache.solr.search.ComplexPhraseQParserPlugin" />
5-) enable it by appending &defType=complexphrase to search url.
6-) Alternatively you can add

"s* b*"
7-) More permanent usage can be configured in solrconfig.xml
<requestHandler name="standard" class="solr.StandardRequestHandler" default="true">
<lst name="defaults">
<str name="defType">complexphrase</str>
</lst>
</requestHandler>

Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email...

http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E

Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed.

A unique token for finding these 240 issues in the future: hossversioncleanup20100527

There is a need for un-ordered proximity search. http://search-lucene.com/m/3W9fj2yzNy82/
Configurable inOrder parameter is added where default behavior is true .

The configuration below can be used to obtain same behavior of PhraseQuery in which order of terms is not important.

 
<queryParser name="complexphrase" class="org.apache.solr.search.ComplexPhraseQParserPlugin">
    <bool name="inOrder">false</bool>
</queryParser>

Hyphen inside the phrase causes exception. e.g. "sulfur-reducing bacteria"
Terje Eggestad's fix is added.

I integrated the patch and its working fine however, there were couple of issues.

One is related to un-ordered proximity which seems to be fixed with the inOrder parameter but its not working for me (doesn't give any error but its still ordered). I will try to get the patch again coz I also merged it in early Nov so maybe it was applied after that.

The other issue is that although proximity search works with phrases BUT its not very accurate e.g. If I want to search "a b" within 10 words of "c" the query would end up being "a b c"~10 but this will also return cases where "a" is not necessarily together with "b". Any scenario where these 3 words are within 10 words of each other will match.

Is it possible in SOLR to do what I mentioned above? Any other patch? Something like " "a b" c "~10...

Note: I was going through Lucene-1486 and there Ahmet mentioned that "Specifically : "(john johathon) smith"~10 " works perfectly. For me it seems there is no difference if I put the parenthesis or not.

Thanks!

Salman, what you are after is nested proximity search which is not currently available in Solr. For alternatives see http://search-lucene.com/m/94ONm1KRuAv1/

Regarding parenthesis inside quotes and inOrder, they are covered in TestCases.

What version of solr did you use?

I am using SOLR 1.4.1 but integrated this patch in early Nov so maybe you committed the inOrder parameter after that?

When you say "Regarding parenthesis inside quotes..." if this works and groups the words in phrase together won't it work for my case e.g. "(a b) c"~10?

I guess if SurroundQuery doesn't use any analyzer it would be very difficult to make the existing queries work (I am using Standard Analyzer).

Use the most recent file which is non-gray color. Also there is a "date attached" info for files.
It works for "(a b) c"~10. This is equivalent to "a c"~10 OR "b c"~10.

SurroundQueryParser does not use Analyzer. It recommended to heavily use wildcard operator instead.
e.g. instead of searching foo bar, you search foo* bar*

But if you are using Standard Analyzer which does not have stemming in it, I think you can use Surround.
You can pre-lowercase your queries etc. You can even pre-analyze your queries since your analyzer does not inject new tokens.
But your queries must be well formed, there is not default operator in this.

But I think it is better to discuss these things in solr/lucene-user mailing list.

I am trying to use CommonGrams with this patch but doesn't seem to work.

If I don't add

it simply does it the old way i.e. ignore CommonGrams.

Can you please help how can I combine both these features?

I tried the patch with latest non-grayed file but still inOrder doesn't seem to have any impact.

Results for "a b"~5 and "b a"~5 are still different.

Also any feedback about CommonGrams integration?

Thanks a lot for all the help!

When you add &debugQuery=on to your search URL, you should see something like in the debug section:
spanNear([text:a, text:b], 5, false) , false here means un-ordered phrase query. Do you see it?

I will look into CommonGrams this weekend.

Hi

I am having same issue (inOrder does not seem to work) with

, in the debug section it shows spanNear([text:a, text:b], 5, true),
my solrconfig.xml looks like

<queryParser name="complexphrase" class="org.apache.solr.search.ComplexPhraseQParserPlugin" >
<bool name="inOrder">false</bool>
</queryParser>

Hi Ahmet

I have read on mailing lists dated "Mon, 20 Jul 2009" that you had merged the surround query parser with solr.
I have tried that by downloading jar file for surround query parser. and then pasting that jar file in web-inf/lib
and configured query parser in solrconfig.xml as
<queryParser name="SurroundQParser" class="org.apache.lucene.queryParser.surround.parser.QueryParser"/>

then web page the following exception comes

org.apache.solr.common.SolrException: Error Instantiating QParserPlugin, org.apache.lucene.queryParser.surround.parser.QueryParser is not a org.apache.solr.search.QParserPlugin

can u guide what i m doing wrong....

Regards
Ahsan

Ahmet,

I would be waiting for your response on CommonGrams. Would be grateful if you can look into it this weekend. Thanks!

Although I would be asking this question on the mailing list as well but since its related to this patch so I wanted to check if this patch would work fine with SurroundQueryParser or if Surround does it itself? This patch functionality is really important for me.

Thanks a lot!

Any updates on integration with CommonGrams? Thanks

Reminder! Any updates regarding integration with CommonGrams? Thanks

Bulk move 3.2 -> 3.3

Will the complexphrase search works fine with e.g. GOK:"PXB 80?", it will throw an exception if there is no space present, e.g. GOK:"PXB80?". The exception is:
Unknown query type "org.apache.lucene.search.WildcardQuery" found in phrase query string "PXB80?"

Update for solr 3.3.0

• Download apache-solr-3.3.0-src.tgz
• Download most latest ComplexPhrase.zip
• 'mvn package' will generate 3 files under target folder
  copy them to apache-solr-3.3.0/solr/lib/
  • cp target/ComplexPhrase-* Downloads/apache-solr-3.3.0/solr/lib/
• call 'ant clean dist' to create a new apache-solr-3.3-SNAPSHOT.war file under solr/dist folder

3.4 -> 3.5

I have installed complexphrase parser and followed all instructions for installation... when i run with defType=complexphrase , i get below error.
HTTP Status 500 - luceneMatchVersion java.lang.NoSuchFieldError: luceneMatchVersion at org.apache.solr.search.SolrComplexPhraseQueryParser

how to solve this. i am new to solr

The class org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser was committed and it's available in "modules/queryparser". How should this patch proceed in order to make that QParser available in Solr? Should it be added to the trunk? as a contrib?

Committed o.a.l.queryparser.complexPhrase.ComplexPhraseQueryParser does not work with non-default fields. Several Lucene users raised this issue on mailing lists. Mark Harwood said the following on LUCENE-1486 which is still unresolved. However it didn't get any attention.

Fixing this would require changing the package name of ComplexPhraseQueryParser or changing the visibility of "field" in the QueryParser base class to "protected".
Anyone have any strong feelings about which of these is the most acceptable?

That's why attachment of this issue is not consuming committed o.a.l.queryparser.complexPhrase.ComplexPhraseQueryParser and released as a solr-plugin.

That's true, but probably this Jira should focus in using the available ComplexPhraseQueryParser and there should be another Jira (a Lucene one) to fix that problem. The parser was moved for a reason and if we use a duplicated version of the parser in a different package (the old one) this will never be committed.

I imagined that LUCENE-1486 will be closed/fixed in the future, hopefully including the non default field patch. Are you saying that non default field problem should be handled in a separate issue (other than LUCENE-1486) ?

It might be LUCENE-1486 or a new Lucene Jira, but what I say is that it should not be fixed in this issue. What I'm proposing is to only provide the necessary classes in Solr to be able to work with the current version of ComplexPhraseQueryParser, even if it is limited in some aspects. Once the ComplexPhraseQueryParser is improved we'll get those improvements in Solr (either automatically or by improving something from this side).

path for trunk

to make inOrder parameter configurable

to enable non-default field searches

In my opinion, we should not be relying on un-committed Lucene code, as it may change or even never get committed. I think this Jira should only consider the current ComplexPhraseQueryParser and we can create a new Solr Jira that depends on LUCENE-3758 for the order/unordered query.

I'm attaching an alternative patch with what I propose:
It works fine with what's committed today in Lucene, it doesn't require LUCENE-3758 committed to compile or LUCENE-1486 committed to run the tests, however, it
has the limitations of the currently committed ComplexPhraseQueryParser.
I have some commented testUnorderedPhraseQuery. It is commented because it currently doesn't run to the the limitations of LUCENE-3758
testFieldedQuery is also commented, as it doesn't run until LUCENE-1486 is committed.
I added testAutogeneratingPhraseQueries, but it is also commented as hyphenated queries don't work when "autogenerate phrase queries" is set to true. This is something we should continue working on in this issue.
I would like to hear opinions on how to continue working.

Did anybody got the chance to see these two patches? are there any more opinions on this?

Bulk changing fixVersion 3.6 to 4.0 for any open issues that are unassigned and have not been updated since March 19.

Email spam suppressed for this bulk edit; search for hoss20120323nofix36 to identify all issues edited

I am upgrading Solr to version 3.6 from version 1.4.1 and applied this patch. The Solr is built successfully. After indexing some document I performed a wildcard phrase query "weekly repo*", no documents were returned. However, by appending "&defType=complexphrase" the solr returned the document containing "weekly report". It seems that the complex phrase is not taken as default search handler.
Also, when restarting solr I discovered following error in log file as:

SEVERE: org.apache.solr.common.SolrException: Error loading class 'org.apache.solr.search.ComplexPhraseQParserPlugin'
at org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:394)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:419)
at org.apache.solr.core.SolrCore.createInitInstance(SolrCore.java:441)
at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1612)
at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1606)
at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1639)
at org.apache.solr.core.SolrCore.initQParsers(SolrCore.java:1556)
at org.apache.solr.core.SolrCore.<init>(SolrCore.java:555)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:483)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:335)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:219)
at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:161)
at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:96)
at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:224)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.mortbay.start.Main.invokeMain(Main.java:194)
at org.mortbay.start.Main.start(Main.java:534)
at org.mortbay.start.Main.start(Main.java:441)
at org.mortbay.start.Main.main(Main.java:119)
Caused by: java.lang.ClassNotFoundException: org.apache.solr.search.ComplexPhraseQParserPlugin
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.net.FactoryURLClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:378)
... 37 more

I would like some help regarding the use of this patch in new solr.

Hi everyone,

Sorry, but I'm green to this stuff. How do I "apply/install" a "*.patch" file?

I downloaded and successfully built (well, "packaged", via mvn) the ComplexPhrase.zip from Jul-2011.

I then downloaded the 'SOLR-1604-alternative.patch' from Feb-2012. I can open and view it via a text editor...but I have no idea what to do to "apply" it? I'm working on a RH Linux box at the moment.

Can anyone guide me and/or point me in the right direction please?

Thanks!
Mike

There are two separate ways to enable this functionality.

• You can consume *.zip attachments as a solr plugin. Which does not require source code modification, but this particular case requires re-creating solr.war. http://wiki.apache.org/solr/SolrPlugins

• *.patch files contains source code modifications. http://wiki.apache.org/solr/HowToContribute#Working_With_Patches

bulk fixing the version info for 4.0-ALPHA and 4.0 all affected issues have "hoss20120711-bulk-40-change" in comment

rmuir20120906-bulk-40-change

Hello all,

Could I get the grammar file (.jj file) for ComplexPhrase one - It's not there as part of the patch/zip file.

Thanks,
Phani.

Could I get the grammar file (.jj file) for ComplexPhrase one - It's not there as part of the patch/zip file.

It does not have a separate grammar file. It just extends QueryPaser.

removing 4.0 from fix version since this depends on LUCENE-1486 which is not already in the 4x branch .. can revist if there is movement on LUCENE-1486

I have noticed that LUCENE-1486 will be fixed in v4.1, and I have found that this patch can not work with solr 4.0. Is there new patch for 4.0?

If there would be a working patch, it could be in 4.0. It was just moved out because nobody took care. It's your turn!

this supposed to work with solr 4.0

Hi, Arslan, when using your patch for 4.0, I got a Exception: java.lang.IllegalArgumentException: Unknown query type "org.apache.lucene.search.PrefixQuery" found in phrase query string "mp*", my query is q=subject:"mp*"&wt=json. This exception was thrown at QueryComponent#process.

Jun Wang query string "mp*" is somehow invalid. Use &q=mp* instead. This parser expects at least two clauses inside quotes.

Includes README.txt that contain instruction for Solr 4.0.0

Hi, I downloaded last version of ComplexPhrase (24/Oct/12 02:30) but have problem with junit test. Here is error log :

test(org.apache.solr.search.ComplexPhraseQParserPluginTest)  Time elapsed: 0.191 sec  <<< ERROR!
java.lang.RuntimeException: Exception during query
	at __randomizedtesting.SeedInfo.seed([4BF35CC9C13F3B15:C3A763136FC356ED]:0)
	at org.apache.solr.util.AbstractSolrTestCase.assertQ(AbstractSolrTestCase.java:283)
	at org.apache.solr.search.ComplexPhraseQParserPluginTest.test(ComplexPhraseQParserPluginTest.java:158)
	// nothing interest here
Caused by: java.lang.IllegalArgumentException: Unknown query type "org.apache.lucene.search.ConstantScoreQuery" found in phrase query string "jo* [sma TO smz]"
	at org.apache.lucene.queryparser.classic.ComplexPhraseQueryParser$ComplexPhraseQuery.rewrite(ComplexPhraseQueryParser.java:297)
	at org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:599)
	at org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:646)
	at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:280)
	at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1385)
	at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1260)
	at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:390)
	at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:411)
	at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:206)
	at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
	at org.apache.solr.core.SolrCore.execute(SolrCore.java:1699)
	at org.apache.solr.util.TestHarness.query(TestHarness.java:364)
	at org.apache.solr.util.TestHarness.query(TestHarness.java:346)
	at org.apache.solr.util.AbstractSolrTestCase.assertQ(AbstractSolrTestCase.java:273)
	... 41 more

Is it error on my side (I didn't change anything)? Or some crucial error?

I also see the error Roman posted, with the latest version

This is ComplexPhrase project based on the version submitted on 21/Jul/11. It compiles and runs under solr 3.4. I have uncommented the tests in /org/apache/solr/search/ComplexPhraseQParserPluginTest.java and they passed.

Hello! Great work!

I have two questions:

1) What would it take to incorporate phrase searches into this extended query parser?
"\"a b\" c"~100
that is, "a b" (phrase search) is found in that order and exactly side by side <=100 tokens away from c.

2) does this implementation support the Boolean operators, like AND, OR, NOT (at least OR and NOT are supported as far as I can see)? Can they be nested?

Hi Ahmet and fellow ComplexPhrase users,

We have been using the ComplexPhraseQueryParser for a number of years with our SOLR installation, but we were hoping to upgrade to SOLR 4.1 and I was just wondering if ComplexPhrase works with the latest SOLR release?

We are still on SOLR 1.4.1 so keen to take advantage of all that SOLR 4.1 can offer, but we can't go there without ComplexPhrase

Much thanks if anyone has anyone has any thoughts.

Bring to 4.2.1 version

Hi Ahmet
I have installed complexphrase parser and followed all instructions for installation...
Everything is fine except getting NULL Pointer exception when I start JBOSS.

19:46:03,909 ERROR [SolrCore] java.lang.NullPointerException
at org.apache.solr.schema.IndexSchema$DynamicReplacement$DynamicPattern$NameEndsWith.matches(IndexSchema.java:960)
at org.apache.solr.schema.IndexSchema$DynamicReplacement.matches(IndexSchema.java:974)
at org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1221)
at org.apache.solr.schema.IndexSchema$SolrQueryAnalyzer.getWrappedAnalyzer(IndexSchema.java:418)
at org.apache.lucene.analysis.AnalyzerWrapper.initReader(AnalyzerWrapper.java:81)
at org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:175)
at org.apache.lucene.queryparser.classic.QueryParserBase.newFieldQuery(QueryParserBase.java:507)
at org.apache.lucene.queryparser.classic.QueryParserBase.getFieldQuery(QueryParserBase.java:495)
at org.apache.lucene.queryparser.classic.QueryParserBase.handleBareTokenQuery(QueryParserBase.java:1109)
at org.apache.lucene.queryparser.classic.QueryParser.Term(QueryParser.java:358)
at org.apache.lucene.queryparser.classic.QueryParser.Clause(QueryParser.java:257)
at org.apache.lucene.queryparser.classic.QueryParser.Query(QueryParser.java:181)
at org.apache.lucene.queryparser.classic.QueryParser.TopLevelQuery(QueryParser.java:170)
at org.apache.lucene.queryparser.classic.QueryParserBase.parse(QueryParserBase.java:121)
at org.apache.lucene.queryparser.classic.ComplexPhraseQueryParser.parse(ComplexPhraseQueryParser.java:107)
at org.apache.solr.search.ComplexPhraseQParser.parse(ComplexPhraseQParserPlugin.java:108)
at org.apache.solr.search.QParser.getQuery(QParser.java:142)
at org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:142)
at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:187)
at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1904)
at org.apache.solr.core.QuerySenderListener.newSearcher(QuerySenderListener.java:64)
at org.apache.solr.core.SolrCore$5.call(SolrCore.java:1693)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Thanks in advance.

Hi ettey siva, what version of solr did you use?

Hi Ahmet
We are using solr 4.4.
Issue was resolved by uncommenting <defaultSearchField>text</defaultSearchField> in schema.xml
Thank you

I have a question about upgrading solr with this plugin. Because the plugin has to be built into solr.war, I need to go through the process each time I upgrade solr. It's rather cumbersome. Does anyone have a better solution?

Rebecca Tang you can define a solr core (even for a single index) and use its lib directory to copy the complex phrase parser jar.

https://cwiki.apache.org/confluence/display/solr/Solr+Cores+and+solr.xml

HTH

Rebecca, for the time being thats the only way to use it. Lib directory fails as explained here : http://search-lucene.com/m/E49gN1naPyh
The problem is fielded queries do not work with current committed CPQP. If LUCENE-1486 gets fixed then this plugin can consume original CPQP.

Ahmet,
I am using solr 4.3.1. do i still need to apply this patch ? if yes please tell me what patch to apply, I see lot of patches here, not sure which patch for what version of solr.

Hi everyone,

Does this plugin supports date searches?
I noticed that doing something like this:
q=Project.CommenceDate:[2006-08-01T00:00:00Z%20TO%202006-08-01T00:00:00Z]

gives no results (When I use edismax it does return some results).
I also tried:
q=Project.CommenceDate:2006-08-01T00:00:00Z

but I get this error:
Invalid Date String:'2006-08-01T00'

Thanks,
Randall Rosales

Two things:

1> dots in field names are risky, in general you should only use valid Java variable naming conventions.
2> How are you submitting this? Because ':' is the delimiter between fields and values, you need to escape this line if you're submitting this via a browser, as 00\:00\:00Z

BTW, you'll get faster responses to this kind of question if you raise it on the user's list, more eyes see it.