Re: Parallel SQL and function queries?

2016-05-23 Thread Joel Bernstein
Also, I believe this syntax should work as well with SQL we'll need to test
it out:

_query_:"{!dismax qf=myfield}how now brown cow"

Joel Bernstein
http://joelsolr.blogspot.com/

On Mon, May 23, 2016 at 2:59 AM, Joel Bernstein  wrote:

> I opened SOLR-9148 and added a patch to pass through filter queries.
>
> I also saw that there is one kind of geo filter that uses the Solr range
> syntax (filtering by rectangle):
>
> store:[45,-94 TO 46,-93]
>
> This should work with the current SQL interface.
>
> We should check with David Smiley and see if there are other Geo-spatial
> queries that will work with the range syntax.
>
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Sun, May 22, 2016 at 10:30 PM, Joel Bernstein 
> wrote:
>
>> Actually, I just reviewed the code and it's not passing through the
>> params as I described.
>>
>> I think this is important to have working so we can support the qparser
>> plugins through filter queries. I'll create a ticket for this and work up a
>> patch for this.
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>> On Sun, May 22, 2016 at 5:16 PM, Joel Bernstein 
>> wrote:
>>
>>> I didn't have a chance yet to fully formulate a strategy for using the
>>> qparser plugins through the SQL interface.
>>>
>>> In the initial release there is a back door that allows you tack on any
>>> parameters you want, and they should be passed through to Solr. There are
>>> no test cases for this, but I can add some to verify this is working. The
>>> idea being that you can do this:
>>>
>>> /sql?stmt=SELECT...&fq={!geofilt ...}
>>>
>>> One of the main things I had in mind with this was allowing access
>>> control lists to be passed in, because Alfresco supports document level
>>> access control which would need to be supported through the SQL interface.
>>>
>>> But any fq should get passed through. it's not clear right now whether
>>> multiple fq's will be passed through, but due to changes that Erick
>>> Erickson recently contributed, I believe they will. Again we need test
>>> cases for this.
>>>
>>> The JDBC driver should pass through any properties that are set on the
>>> connection as well. Again I was mostly thinking about access control here
>>> but other qparsers can be added as well.
>>>
>>> This was not meant as the long term solution though. In future releases
>>> I think we should roll out as many function queries and qparser plugins as
>>> possible as SQL functions.
>>>
>>>
>>>
>>>
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/
>>>
>>> On Sun, May 22, 2016 at 3:11 PM, Timothy Potter 
>>> wrote:
>>>
 How would I do something like: find all docs using a geofilt, e.g.

 SELECT title_s
   FROM movielens
 WHERE location_p='{!geofilt d=90 pt=37.773972,-122.431297
 sfield=location_p}'

 This fails with:

 {"result-set":{"docs":[
 {"EXCEPTION":"java.util.concurrent.ExecutionException:
 java.io.IOException: -->

 http://ec2-54-165-55-141.compute-1.amazonaws.com:8984/solr/movielens_shard2_replica1/:Can't
 parse point '{!geofilt d=90 pt=37.773972,-122.431297
 sfield=location_p}' because: java.lang.NumberFormatException: For
 input string: \"{!geofilt d=90
 pt=37.773972\"","EOF":true,"RESPONSE_TIME":4}]}}

 In general, I wasn't able to find much about using functions with
 local params in the SQL syntax?

>>>
>>>
>>
>


Re: Parallel SQL and function queries?

2016-05-22 Thread Joel Bernstein
I opened SOLR-9148 and added a patch to pass through filter queries.

I also saw that there is one kind of geo filter that uses the Solr range
syntax (filtering by rectangle):

store:[45,-94 TO 46,-93]

This should work with the current SQL interface.

We should check with David Smiley and see if there are other Geo-spatial
queries that will work with the range syntax.



Joel Bernstein
http://joelsolr.blogspot.com/

On Sun, May 22, 2016 at 10:30 PM, Joel Bernstein  wrote:

> Actually, I just reviewed the code and it's not passing through the params
> as I described.
>
> I think this is important to have working so we can support the qparser
> plugins through filter queries. I'll create a ticket for this and work up a
> patch for this.
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Sun, May 22, 2016 at 5:16 PM, Joel Bernstein 
> wrote:
>
>> I didn't have a chance yet to fully formulate a strategy for using the
>> qparser plugins through the SQL interface.
>>
>> In the initial release there is a back door that allows you tack on any
>> parameters you want, and they should be passed through to Solr. There are
>> no test cases for this, but I can add some to verify this is working. The
>> idea being that you can do this:
>>
>> /sql?stmt=SELECT...&fq={!geofilt ...}
>>
>> One of the main things I had in mind with this was allowing access
>> control lists to be passed in, because Alfresco supports document level
>> access control which would need to be supported through the SQL interface.
>>
>> But any fq should get passed through. it's not clear right now whether
>> multiple fq's will be passed through, but due to changes that Erick
>> Erickson recently contributed, I believe they will. Again we need test
>> cases for this.
>>
>> The JDBC driver should pass through any properties that are set on the
>> connection as well. Again I was mostly thinking about access control here
>> but other qparsers can be added as well.
>>
>> This was not meant as the long term solution though. In future releases I
>> think we should roll out as many function queries and qparser plugins as
>> possible as SQL functions.
>>
>>
>>
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>> On Sun, May 22, 2016 at 3:11 PM, Timothy Potter 
>> wrote:
>>
>>> How would I do something like: find all docs using a geofilt, e.g.
>>>
>>> SELECT title_s
>>>   FROM movielens
>>> WHERE location_p='{!geofilt d=90 pt=37.773972,-122.431297
>>> sfield=location_p}'
>>>
>>> This fails with:
>>>
>>> {"result-set":{"docs":[
>>> {"EXCEPTION":"java.util.concurrent.ExecutionException:
>>> java.io.IOException: -->
>>>
>>> http://ec2-54-165-55-141.compute-1.amazonaws.com:8984/solr/movielens_shard2_replica1/:Can't
>>> parse point '{!geofilt d=90 pt=37.773972,-122.431297
>>> sfield=location_p}' because: java.lang.NumberFormatException: For
>>> input string: \"{!geofilt d=90
>>> pt=37.773972\"","EOF":true,"RESPONSE_TIME":4}]}}
>>>
>>> In general, I wasn't able to find much about using functions with
>>> local params in the SQL syntax?
>>>
>>
>>
>


Re: Parallel SQL and function queries?

2016-05-22 Thread Joel Bernstein
Actually, I just reviewed the code and it's not passing through the params
as I described.

I think this is important to have working so we can support the qparser
plugins through filter queries. I'll create a ticket for this and work up a
patch for this.

Joel Bernstein
http://joelsolr.blogspot.com/

On Sun, May 22, 2016 at 5:16 PM, Joel Bernstein  wrote:

> I didn't have a chance yet to fully formulate a strategy for using the
> qparser plugins through the SQL interface.
>
> In the initial release there is a back door that allows you tack on any
> parameters you want, and they should be passed through to Solr. There are
> no test cases for this, but I can add some to verify this is working. The
> idea being that you can do this:
>
> /sql?stmt=SELECT...&fq={!geofilt ...}
>
> One of the main things I had in mind with this was allowing access control
> lists to be passed in, because Alfresco supports document level access
> control which would need to be supported through the SQL interface.
>
> But any fq should get passed through. it's not clear right now whether
> multiple fq's will be passed through, but due to changes that Erick
> Erickson recently contributed, I believe they will. Again we need test
> cases for this.
>
> The JDBC driver should pass through any properties that are set on the
> connection as well. Again I was mostly thinking about access control here
> but other qparsers can be added as well.
>
> This was not meant as the long term solution though. In future releases I
> think we should roll out as many function queries and qparser plugins as
> possible as SQL functions.
>
>
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Sun, May 22, 2016 at 3:11 PM, Timothy Potter 
> wrote:
>
>> How would I do something like: find all docs using a geofilt, e.g.
>>
>> SELECT title_s
>>   FROM movielens
>> WHERE location_p='{!geofilt d=90 pt=37.773972,-122.431297
>> sfield=location_p}'
>>
>> This fails with:
>>
>> {"result-set":{"docs":[
>> {"EXCEPTION":"java.util.concurrent.ExecutionException:
>> java.io.IOException: -->
>>
>> http://ec2-54-165-55-141.compute-1.amazonaws.com:8984/solr/movielens_shard2_replica1/:Can't
>> parse point '{!geofilt d=90 pt=37.773972,-122.431297
>> sfield=location_p}' because: java.lang.NumberFormatException: For
>> input string: \"{!geofilt d=90
>> pt=37.773972\"","EOF":true,"RESPONSE_TIME":4}]}}
>>
>> In general, I wasn't able to find much about using functions with
>> local params in the SQL syntax?
>>
>
>


Re: Parallel SQL and function queries?

2016-05-22 Thread Joel Bernstein
I didn't have a chance yet to fully formulate a strategy for using the
qparser plugins through the SQL interface.

In the initial release there is a back door that allows you tack on any
parameters you want, and they should be passed through to Solr. There are
no test cases for this, but I can add some to verify this is working. The
idea being that you can do this:

/sql?stmt=SELECT...&fq={!geofilt ...}

One of the main things I had in mind with this was allowing access control
lists to be passed in, because Alfresco supports document level access
control which would need to be supported through the SQL interface.

But any fq should get passed through. it's not clear right now whether
multiple fq's will be passed through, but due to changes that Erick
Erickson recently contributed, I believe they will. Again we need test
cases for this.

The JDBC driver should pass through any properties that are set on the
connection as well. Again I was mostly thinking about access control here
but other qparsers can be added as well.

This was not meant as the long term solution though. In future releases I
think we should roll out as many function queries and qparser plugins as
possible as SQL functions.




Joel Bernstein
http://joelsolr.blogspot.com/

On Sun, May 22, 2016 at 3:11 PM, Timothy Potter 
wrote:

> How would I do something like: find all docs using a geofilt, e.g.
>
> SELECT title_s
>   FROM movielens
> WHERE location_p='{!geofilt d=90 pt=37.773972,-122.431297
> sfield=location_p}'
>
> This fails with:
>
> {"result-set":{"docs":[
> {"EXCEPTION":"java.util.concurrent.ExecutionException:
> java.io.IOException: -->
>
> http://ec2-54-165-55-141.compute-1.amazonaws.com:8984/solr/movielens_shard2_replica1/:Can't
> parse point '{!geofilt d=90 pt=37.773972,-122.431297
> sfield=location_p}' because: java.lang.NumberFormatException: For
> input string: \"{!geofilt d=90
> pt=37.773972\"","EOF":true,"RESPONSE_TIME":4}]}}
>
> In general, I wasn't able to find much about using functions with
> local params in the SQL syntax?
>


Parallel SQL and function queries?

2016-05-22 Thread Timothy Potter
How would I do something like: find all docs using a geofilt, e.g.

SELECT title_s
  FROM movielens
WHERE location_p='{!geofilt d=90 pt=37.773972,-122.431297 sfield=location_p}'

This fails with:

{"result-set":{"docs":[
{"EXCEPTION":"java.util.concurrent.ExecutionException:
java.io.IOException: -->
http://ec2-54-165-55-141.compute-1.amazonaws.com:8984/solr/movielens_shard2_replica1/:Can't
parse point '{!geofilt d=90 pt=37.773972,-122.431297
sfield=location_p}' because: java.lang.NumberFormatException: For
input string: \"{!geofilt d=90
pt=37.773972\"","EOF":true,"RESPONSE_TIME":4}]}}

In general, I wasn't able to find much about using functions with
local params in the SQL syntax?