The question is simple. How to do a case-insensitive searching with JMESPath?
Let's say to search for foo in this JSON:
[
"foo",
"foobar",
"barfoo",
"bar",
"baz",
"barbaz",
"FOO"
]
Here is the case-sensitive search query:
[?contains(#, 'foo')]
It will returns ["foo", "foobar", "barfoo"] but it misses "FOO".
[?contains(lower(#), lower('string_you_want_to_search')]
We could convert both search strings into lower or upper case to get case insensitive search.
https://jmespath.site/#preview Latest preview has support for it.
JEP discussion https://github.com/jmespath-community/jmespath.spec/discussions/21
Related
Why does this term match everything:
{result: $and[{$exists:true}, {$ne: 0}]}
{result:{$exists:true}, result:{$ne:0}} (this too as suggested)
The idea was to match fields, which have a key "result" and are where result is not equal zero. Why this does match a document, which only has a oid?
edit:
What works as expected is the following:
{ $and: [ { result:{$exists:true}}, {result:{$ne: 0}}]}
The question is still the same, why do those queries behaive like this?
try:
{result:{$exists:true}, result:{$ne:0}}
I have a problem with Oracle ORDS escaping my GeoJSON with "
{
"id": 1,
"city": "New York",
"state_abrv": "NY",
"location": "{\"type\":\"Point\",\"coordinates\":[-73.943849, 40.6698]}"
}
In Oracle DB it is stated correctly:
{"type":"Point","coordinates":[-73.943849, 40.6698]}
Need help to figure out why the " are added and how to prevent this from happening
add this column alias to your restful service handler query for the JSON column
SELECT id,
jsons "{}jsons" --this one
FROM table_with_json
Then when ords sees the data for the column, it won't format it as JSON because it already IS json
You can use whatever you want, in your case it should probably be
"{}location"
In our controller, we are trying to show a video series, which should return JSON similar to this:
{
id: 1,
name: "Series Name",
videos: [
id: 2,
name: "Video Name",
isInPlaylist: true,
isFavorite: false
]
}
We are adding the isInPlaylist and isInFavorite attributes via another table where we store data if a user has acted upon a video (rated it, favorited it, etc.).
videos = series.videos
.where('videos.is_live = true')
.joins("some join to user_videos join_table")
.select(
'videos.*,
coalesce(user_videos.rating, 0.0) as user_rating,
coalesce(user_videos.enqueue, \'false\') as isInPlaylist,
coalesce(user_videos.favorite, \'false\') as isFavorite'
)
Note that in our select statement those attributes are explicitly aliased as camel-cased values. However when we execute this query, these attributes are returned lower case instead:
{
isinplaylist: true,
isfavorite: false
}
This is not a Rails behavior, but rather a SQL behavior. Alias's are folded to lower case unless explicitly quoted. For an example, here is the output of a simple query in psql (the Postgres CLI program).
=# select created_at as theTimeNow from users limit 5;
thetimenow
----------------------------
2013-03-05 18:45:11.127092
2013-09-07 16:43:01.349823
2013-03-05 18:53:35.888306
2013-09-07 16:53:06.553129
2013-10-29 00:38:56.909418
(5 rows)
=# select created_at as "theTimeNow" from users limit 5;
theTimeNow
----------------------------
2013-03-05 18:45:11.127092
2013-09-07 16:43:01.349823
2013-03-05 18:53:35.888306
2013-09-07 16:53:06.553129
2013-10-29 00:38:56.909418
(5 rows)
Notice the column name outputs
Wrapping the alias in double quotes preserves case-sensitivity.
.select('foo as Bar') # => { bar: true }
.select('foo as "Bar"') # => { Bar: true }
The change to lower case is not an issue with the Rails .select() method but is enforced by the DB, in our case PostgreSQL, and is a practice called "Folding". Its worth noting that while PSQL will fold to lowercase letters, mySQL will fold to upper case letters.
I would argue however that it should still be included in the Rails API docs
¯\_(ツ)_/¯
I like you answer. The behaviour you see is rails default. As an alternative and
a more classic 'rails way' would be to use a json serializing library like jBuilder. It gives you lot more control over your API but your problem would be easy to fix in that using:
json.key_format! camelize: :lower
json.first_name 'David'
# => { "firstName": "David" }
To use something like this you would alias the columns as is_in_playlist format.
Here's a good place to start with jBuilder learning:
http://railscasts.com/episodes/320-jbuilder
Good tutorial on more json serializers:
http://railscasts.com/episodes/409-active-model-serializers
I inherited a database loaded into DocumentDB, where field name happens to be "Value".
Example of my structure is:
{
...
"Alternates": [
"Type": "ID",
"Value" : "NOCALL"
]
}
when I query (using documentDB's SQL), trying to get back all documents where Alternates.Value = "NOCALL", I get syntax error near
"Value" error
. If I query for Type = "ID", it is all fine.
Seems that the word Value, having a special meaning on DocumentDB is causing an issue.
Putting punctuation (e.g. quotes/double quotes) around "Value" does not seem to help.
Any suggestion on how to resolve this will be much appreciated!
Thank you in advance!
You are correct. Value is a reserved keyword.
To escape this use [""] syntax.
So in your case of
"Alternates": [
"Type": "ID",
"Value" : "NOCALL"
]
SELECT c
FROM c
JOIN alt IN c.Alternates
WHERE alt["Value"] = 'NOCALL'
In my case, the structure looks something like this - { "name": "ABC", "Value": 123 }.
I could escape the reserved keyword using [""] (as answered by others) along with <source_name> i.e.
SELECT c["Value"] FROM c -- 123
Ref.: Querying in Azure Cosmos DB
I have three food type indices "Italian", "Spanish", "American".
When the user searches "Cheese", documents from "Italian" appear to come up at the top. Is it possible to "boost" the results if I were to give preference to say "Spanish"? (I should still get results for Italian, but based on some numeric boost value for index type "Spanish", the ordering of the documents returned in the results give preference to the "Spanish" index. Is this possible in user input lucene and/or ES query? If so, how?
Add a term query with a boost for either the _type field or the _index (or both).
Use a script_score as part of the function score query:
function_score: {
script_score: {
script: "doc['_type'].value == '<your _type>' ? _score * <boost_factor> : _score"
}
}
If querying several indices at once, it is possible to specify indices boost at the top level of object passed to Search API:
curl -XGET localhost:9200/italian,spanish,american/_search -d '
{
"query":{"term":{"food_type":"cheese"}},
"indices_boost" : {
"ilalian" : 1.4,
"spanish" : 1.3,
"american" : 1.1
}
}'
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-index-boost.html#search-request-index-boost
For query-time boosting, queries (ex. query string) generally have a boost attribute you can set. Alternatively, you can wrap queries in a custom boost factor. I would probably prefer the former, usually.