Complement of {!join}

[Bruce Johnson]

=== Short-version ===
Is there a way to join on the complement of a query? I want the only the
Solr documents for which the nested join query does not match.

=== Longer-version ===
Query-time joins with {!join} are great at modeling the SQL equivalent of
patterns like this:

SELECT book_name FROM books WHERE id
IN (SELECT book_id FROM chapters WHERE chapter_title = "Foo")

This would find the name of books having chapters entitled "Foo". (Assuming
the chapters table have the column 'book_id' that point back to the book
record containing them.)

That's great.

Is there a way in Solr to query for the complement of that? In SQL terms,
this:

SELECT book_name FROM books WHERE id
NOT IN (SELECT book_id FROM chapters WHERE chapter_title = "Foo")

This would find books that do not have chapters entitled "Foo".

It isn't the same as querying (in Solr terms) for something like

{!join to=id from=book_id}-chapter_title:"Foo" // note the negation

because it would still match other chapters in the same book that are not
entitled "Foo", causing the join to still identify the book based on its
other non-Foo chapters.

Any advice would be greatly appreciated. I'm also open to other ways of
thinking about the problem. Perhaps there are alternative indexing patterns
that could accomplish the same goal.

Many thanks,
Bruce

Re: Complement of {!join}

[Bruce Johnson]

Thank you so much for the quick reply, Erik. And wow: I didn't realize you
could use join that fluidly. Very nice.

Is there some trove of Solr doc that I'm missing where this natural syntax
is explained? I wouldn't have asked such a basic question except that I
found no evidence that this was possible.




On Wed, Jul 9, 2014 at 12:07 PM, Erik Hatcher 
wrote:

> Maybe something like q=*:* AND NOT {!join … } would do the trick?  (it’ll
> depend on your version of Solr for support of the {!…} more natural nested
> queries)
>
> Erik
>
> On Jul 9, 2014, at 11:24 AM, Bruce Johnson 
> wrote:
>
> > === Short-version ===
> > Is there a way to join on the complement of a query? I want the only the
> > Solr documents for which the nested join query does not match.
> >
> > === Longer-version ===
> > Query-time joins with {!join} are great at modeling the SQL equivalent of
> > patterns like this:
> >
> > SELECT book_name FROM books WHERE id
> > IN (SELECT book_id FROM chapters WHERE chapter_title = "Foo")
> >
> > This would find the name of books having chapters entitled "Foo".
> (Assuming
> > the chapters table have the column 'book_id' that point back to the book
> > record containing them.)
> >
> > That's great.
> >
> > Is there a way in Solr to query for the complement of that? In SQL terms,
> > this:
> >
> > SELECT book_name FROM books WHERE id
> > NOT IN (SELECT book_id FROM chapters WHERE chapter_title = "Foo")
> >
> > This would find books that do not have chapters entitled "Foo".
> >
> > It isn't the same as querying (in Solr terms) for something like
> >
> > {!join to=id from=book_id}-chapter_title:"Foo" // note the negation
> >
> > because it would still match other chapters in the same book that are not
> > entitled "Foo", causing the join to still identify the book based on its
> > other non-Foo chapters.
> >
> > Any advice would be greatly appreciated. I'm also open to other ways of
> > thinking about the problem. Perhaps there are alternative indexing
> patterns
> > that could accomplish the same goal.
> >
> > Many thanks,
> > Bruce
>
>

Does soft commit block on autowarming?

[Bruce Johnson]

I currently have an algorithm that needs to know whether query results are
fresh up to a known point in time, and I'm using an explicit soft commit
request to act as a latch point. I record the time T just before I issue a
soft commit request, and when it returns, I assume that query results
include all documents indexed prior to T. (Note that I record T *prior* to
issuing the soft commit request, to avoid the obvious race.)

Is that sound? Is it reliably true that once a soft commit request returns,
any subsequent queries will hit a new (and autowarmed) searcher? I'm
specifically wondering whether Solr might continue to autowarm a new
pending searcher in the background after claiming to finish the soft commit
and then at some unknown point later switch to the newer searcher, such
that queries can hit a stale searcher accidentally.

Hope that question makes sense. Any help, pointers to code, whatever, would
be greatly appreciated!

- Bruce