patch for trunk

ok guys try to bare with me, since I don't know this thing at all:

Would this apply to both exact and sloppy phrase queries?

It seems to me, that instead of hardcoding inOrder to true, we should only set inOrder=true if its an exact phrase query
But if the user (not this qp itself, but the user actually used ~) supplied slop, then inOrder should be false.

This would better emulate the behavior of the regular lucene queryparser... I'm wondering if we even need an option
since it just seems like the way it should work.

Hello!

If I were to implement two different versions of span near queries: with order and without order, would this class be the right point to start?
I'm thinking to add support for new query operator that would support order of terms in the near query, as (if I correctly understand), "~" operator doesn't preserve the order.

Implemented new query operator "#", that allows to do what's described in my previous message. Let me know, if someone needs a "patch" for this.

Basically, a search like '"foo bar"#2' would match documents with the terms "foo" and "bar" with up to 2 positions of distance from each other and only if "foo" is before "bar"?

That's correct Tomás. We have already internally tested this operator and it works just fine.

I think that makes sense. The query is different so it should have a different syntax.

Bulk move 4.4 issues to 4.5 and 5.0

patch for trunk (revision 1577942)

Just to make sure I understand Dimitry's comment about the # operator. I don't see anything in this patch on a quick look that references a new operator, so that's a separate issue, correct? I see in the related SOLR-1604 patch the ability to specify inOrder="true|false" as a local parameter, so this functionality is available at that level.

Frankly, I'd rather not introduce a new operator at this stage, let's get the underlying functionality in place and treat any new operators as a separate issue if we add one it at all.

Any responses to the comment by Robert Muir? My quick response is that I've seen use-cases like this:
"Find all the variants of "john anderson, including 'jonathan anderson', 'jon ivan gregory anderson' but not 'eric anderson and jonathan jones' ". Contrived a bit, but you get the idea. Specifying slop doesn't allow this case, but slop with specified order does.

I'm going to be committing this this, along with SOLR-1604 today unless there are objections. The patch doesn't change current behavior so it seems pretty safe.

Ahmet's patch plus entry in CHANGES.txt

Fixed:
trunk: r - 1578113
4x: r - 1578134

Thanks Ahmet!

Erick Erickson right, agree, this should be handled in another jira as a local param. We have implemented this as an operator as we allow mixing ordered and unordered clauses in the same query.

Close issue after release of 4.8.0