Solr 7.5 parsing phrase query wrong - parsing

Here is the query our code produces when searching for a phone number.
(DOC_DTG:[2010-01-01T00:00:00Z TO 9999-12-31T23:59:59Z] OR (*:* NOT DOC_DTG:[* TO *])) AND "(972) 492 - 5495"
When i run it in the solr ui the area code shows up twice in the parsed query. The parsed query look like this:
+(DOC_DTG:[1262304000000 TO 253402300799000] (*:* -DOC_DTG:[-9223372036854775808 TO 9223372036854775807])) +DOC_TEXT:"(972 (972)) 492 - 5495
We're using the LuceneQParser:
"QParser":"LuceneQParser"
Why does the area code show up twice?
I tried escaping the parenthesis and the space still the same outcome. When I remove the parenthesis everything is fine. Any help would be great.

Related

Blazer - Escape Characters

I feel like I am missing something, but I could not find it in the documentation on GH.
What are the escape characters for Blazer when searching in a string that contains a ' or ".
Example:
SELECT * FROM "search_filters"
where "params" like '%with_vehicles_id"=>[%'
LIMIT 100
Update:
The underlying database is Postgres 11. This is a blazer tool question, as the query above works just fine in a tool like dBeaver, or console. For some reason, I believe this is related to how Blazer is parsing the query before it is sent.
I'm not very familiar with Blazer but it looks like it's a BI tool that lets your run SQL queries against your database and there's a playground here.
For PostgreSQL you don't need to do anything special for a double-quote inside of single quotes. The query as you wrote it would execute in a postgres terminal and the same approach works in the blazer playground.
SELECT * FROM "search_filters"
where "params" like '%text"text%'
LIMIT 100
To query on a string that includes a single quote, PosgreSQL has you use two sequential single quotes, like this:
SELECT * FROM "search_filters"
where "params" like '%text''text%'
LIMIT 100
Here's a link with more information:
https://www.prisma.io/dataguide/postgresql/short-guides/quoting-rules
-- UPDATE --
Based on your error message ("syntax error at or near "LIMIT" LINE 3: LIMIT 100 LIMIT 1000") it looks like there are two "LIMIT" clauses being added to the SQL query. Do you have gems/plugins that are modifying the query and is there a way to disable them to see if that's causing the problem?

Splunk Streamlined search for specific fields only

I've ran out of GoogleFu, so if anyone can point me in the right direction or a better term or two to Google... I'm trying to figure out Splunk SPL syntax to search 4 different fields for the same value, any match in the four fields wins, with out searching every field for the TERM(<IP>).
index="main" packets_out>0 action="allowed" TERM(192.168.2.1)
| fields src_ip, dest_ip, dest_translated_ip, src_translated_ip,packets_out
| head 10
These will always be constant: index="main" packets_out>0 action="allowed"
The IP will be the only variable that will change and I'm trying to make it as simple as possible for others to "open search, change 1 IP, click go".
This works as is, but once I try to search against prod with 2000 devices.. I'm expecting my query time will not be 1 second anymore, even with using "Fast Mode" search. I've reduced the 4 second query time to 1. Along with the size of data queried with this already, in my home lab, but I don't think this is going to scale very well.
Is there a better way to do this, besides plugging in 10-20 device names into the query like this? I would rather not have static device names, so if someone "forgets" to update the query; I'll get blamed for the external IP overlap issue.
index="main" packets_out>0 action="allowed" TERM(192.168.2.1) dvc_name="firewall1" OR dvc_name="firewall2" <*18>
| fields src_ip, dest_ip, dest_translated_ip, src_translated_ip,packets_out
| head 10
Raw log if needed:
Apr 7 23:59:55 192.168.2.1 Apr 7 23:59:55 wall 1,2021/04/07 23:59:54,012801092758,TRAFFIC,end,2560,2021/04/07 23:59:54,192.168.2.189,173.194.219.94,10.10.10.2,173.194.219.94,web_access_out-1,,,quic,vsys1,trust,untrust,ethernet1/8,ethernet1/2,splunk,2021/04/07 23:59:54,2004,1,53384,443,59427,443,0x400050,udp,allow,5528,2350,3178,15,2021/04/07 23:57:53,1,any,0,5261883,0x0,192.168.0.0-192.168.255.255,United States,0,6,9,aged-out,0,0,0,0,,wall,from-policy,,,0,,0,,N/A,0,0,0,0,f863e426-7e87-4999-b5cb-bc6dc38d788f,0,0,,,,,,,,0.0.0.0,,,,,,,,,,,,,,,,,,,,,,,,,,,2021-04-07T23:59:55.282-04:00,,
Thanks,
Use OR:
index=ndx sourcetype=srctp (fieldA="myval" OR fieldB="myval" OR fieldC="myval")
Parenthesis added for clarity/readability

Array Formula not counting correctly

I have one array formula which is behaving differently to all of my others.
https://docs.google.com/spreadsheets/d/150rfbeuUW9RuG-iX6EGZAP83iOGr0KG_pn1ts-SXKoU/edit?usp=sharing
I just can't get 'Country Rating'!H2 to return the results I want and for some reason isn't counting the data in D:D correctly. 'Country Rating'!J2 is almost identical and seems to be working fine. I've narrowed it down to being an issue relating to the last "-" in the H2 formula but can't get any further.
I'm sure this is a very basic thing that I'm missing but it's driving me mad!
You need to use those regex matches '.*Vegetarian.*' and matches '.*Vegan.*' as matches returns true only in case of a full match.
Also .*Vegan* was missing . before the last *, meaning zero or more n chars at the end.
And be aware that regex in matches is case sensitive and flags do not work there: you cannot use this (?i).*vegan.* for example.

InfluxDB query with tag where clause not returning results

this looks like something really straightforward that I am messing up, but can't find what is wrong. I have a simple query where I am trying to retrieve measurements with a specific tag value. I am following the syntax of double quoting the tag_key and single quoting the tag value. E.g., select "score","i_unique"::tag from "events.flow" where "i_unique" = 'my-value'
If you see below:
> select "score","i_unique"::tag from "events.flow" limit 4
name: events.flow
time score i_unique
---- ----- --------
1563464912039000000 462 "42422440-41124048-155896-42266768-229624-233640"
1563464912042000000 462 "42422440-41124048-155896-42266768-42352808-42270864"
......
> select "score","i_unique"::tag from "events.flow" where "i_unique" = '42422440-41124048-155896-42266768-229624-233640'
>
The tag value I want to query for, is in the time series as can be seen by the first select query. But, when I want to pick up just that value by adding a where clause, I am not getting any results.
Any help would be wonderful, Thank You.
Turns out there was an error on my insert. I was inserting an additional double quote for my tag. It is obvious now, when I look at the result of the search query, but missed it completely. So this was a problem with my insert and not select. Once I removed the additional "s, everything is making sense again.

GSheets - How to query a partial string

I am currently using this formula to get all the data from everyone whose first name is "Peter", but my problem is that if someone is called "Simon Peter" this data is gonna show up on the formula output.
=QUERY('Data'!1:1000,"select * where B contains 'Peter'")
I know that for the other formulas if I add an * to the String this issue is resolved. But in this situation for the QUERY formula the same logic do not applies.
Do someone knows the correct syntax or a workaround?
How about classic SQL syntax
=QUERY('Data'!1:1000,"select * where B like 'Peter %'")
The LIKE keyword allows use of wildcard % to represent characters relative to the known parts of the searched string.
See the query reference: developers.google.com/chart/interactive/docs/querylanguage You could split firstname and lastname into separate columns, then only search for firstnames exactly equal to 'Peter'. Though you may want to also check if lowercase/uppercase where lower(B) contains 'peter' or whitespaces are present in unexpected places (e.g., trim()). You could also search only for values that start with Peter by using starts with instead of contains, or a regular expression using matches. – Brian D
It seems that for my case using 'starts with' is a perfect fit. Thank you!

Resources