I want to pass disjunction of conjunctions in keyword parameter.
For example:
keyword=pizza AND hrs OR pizza AND family
I'm executing the following request:
https://maps.googleapis.com/maps/api/place/search/json?location=41.141,-73.2631&radius=25000&types=restaurant&keyword=pizza+hrs|pizza+family&sensor=false
I'm not sure whether
keyword=pizza+hrs|pizza+family
is equivalient logicaly to the following expression.
keyword=(pizza AND hrs) OR (pizza AND family)
Any ideas is it true?
Thanks in advance
Places API does not support disjunctions or conjunctions in the keyword parameter. Please feel free to request this feature in our issue tracker: Places API Feature Request
Thanks!
Related
We are trying to create a #Search method in a FHIR Server to look for all the observations from a Patient. I have seen that the parameter can be subject or patient. We want that you could look for a Patient by Identifier, so the request should be something like this:
GET [base]/Observation?subject:identifier=http://acme.org/fhir/identifier/mrn|123456
or
GET [base]/Observation?patient:identifier=http://acme.org/fhir/identifier/mrn|123456
Our problem is that we only have Patient Identifiers with type. In order to look for a Patient by Identifier with type, you have to add the modifier :of-type. My question is, is correct to have a request with two modifiers? Just like the example below
GET [base]/Observation?patient:identifier:of-type=http://terminology.hl7.org/CodeSystem/v2-0203|MR|446053
Modifiers modify the default search behaviour, not the filter that you want to put on the resource type. You can only use modifier specified by FHIR. They are listed on this page: http://hl7.org/fhir/search.html.
Your first two searches above are not valid. In order to search Observations based on a patient's identifier, you would have to do a chained search:
GET [base]/Observation?patient.identifier=http://acme.org/fhir/identifier/mrn|123456
This is a shortcut for 'subject' with a resource type modifier:
GET [base]/Observation?subject:Patient.identifier=http://acme.org/fhir/identifier/mrn|123456
If you need to incorporate the 'of-type' modifier, the search could look like this:
GET [base]/Observation?patient.identifier:of-type=[codesystem_for_type]|MR|123456
I prefer to use the 'patient' parameter whenever applicable, but it would also be valid to do subject:Patient.identifier:oftype. Edit to add: for now it is valid, but see Lloyd's answer for future FHIR versions.
Based on https://jira.hl7.org/browse/FHIR-20641, the intention is to clarify that multiple modifiers are prohibited and that if you have that requirement, you need to define your own search parameter that doesn't require modifiers. Note that this decision has not yet passed ballot. In R4, there is no documented expectation for support, but there's no prohibition either. In practice, we're not aware of any standard servers that provide support and, given the planned prohibition in R5, it's unlikely such support will be built.
Good day to everyone.
I was trying to test Strapi API in one of my projects.
Case Example: user searches for people who know various languages. The user will enter the languages, and it should filter out the people who “contain” all the languages which were selected. Basically the result should be the people who have the languages selected as a subset of their languages array.
I tried to do it using “contains” and “and”. But this doesn’t give the desired result.It gives the result for "or". After spending hours on this, it would be great if someone could help me.
Thanks in advance
_where[0][languages_contains]=1&_where[1][languages_contains]=2
_where[0][languages_in]=[1]&_where[1][languages_in]=[2]
this might work in your case
The parameter _sort in hapi fhir 4.2 shows a strange behaviour. While a query without any conditions like /Procedure returns all existing procedures, a sorted query like /Procedure?_sort=date returns only procedures having a date != null.
From a developers perspective one might say: Ok, I don't have a value to sort by, so I can't make an assertation, but practically this makes the _sort parameter completely useless for fields that can be null.
Why is a value of Null not treated as the least possible value for the field, like in sql or other ?
I got through the Hapi fhir changelog, but havn't found this issue mentioned ( for me, it is an issue )
I know that sort parameters are based on search parameters. Does anyone know whether there is a chance to change this behaviour by any option in the searchparameter ?
I guess No :-(
Cheers
Christian
I'm reading parse API documentation at https://parse.com/docs/rest/guide#queries and can't find how to search by a substring. SQL equivalent would be:
... WHERE column_name LIKE "%foo%"
There's a bunch of options such as >, <, &in, and similar, but there's no option for LIKE. It's pretty common use case... What am I missing?
We've found something that looks like an undocumented feature.
There's a $regex lookup it's not mentioned in the official API reference. It allows for matching by regular expressions which solved the problem for us.
We believe it should be documented here:
https://parse.com/docs/rest/guide/#queries-query-constraints
But apparently it isn't.
In your case, I think you should follow Parse's tutorial here: http://blog.parse.com/learn/engineering/implementing-scalable-search-on-a-nosql-backend/
It is very helpful in terms of search. The main ideas are:
Separate the texts into single words and store as in array
Then perform search on the new field using containedIn(or $in as in REST API) query.
There's also a question regarding this too: How to make a "like" query in Parse.com
EDIT: New blog link: https://web.archive.org/web/20150416171914/http://blog.parse.com/2013/03/19/implementing-scalable-search-on-a-nosql-backend/
for example i have an xpath and wish to add a comment near it to identify it.
/html/body/div/table/tr/td/a{this is a link}
XPATH 2.0 does allow comments.
From http://www.w3.org/TR/xpath20/#comments:
Comments may be used to provide informative annotation for an
expression. Comments are lexical constructs only, and do not affect
expression processing.
Comments are strings, delimited by the symbols (: and :). Comments may
be nested.
A comment may be used anywhere ignorable whitespace is allowed (see
A.2.4.1 Default Whitespace Handling).
The following is an example of a comment:
(: Houston, we have a problem :)
Bad news if we ever need to parse XML containing emoticons! :-)
As an aside - as I was looking for this info in the context of working with Tibco Designer for BusinessWorks v5.x, where comments can be added within the TIBCO Designer XPATH formula builder using:
{-- Houston, we've had a problem --}
Not a comment syntax, but you can give string literals as predicate, which evaluates as true (imho) and should not change the outcome of the expression. I don't know if this has big performance drawbacks.
/html/body/div/table["this is"]["a table"]/tr/td/a["this is a link"]
But like mjv said, I also would stick to the syntax of the host language.
2019 edit
As pointed out in #Sepster's reply and elsewhere, starting with XPath 2.0, comments became possible with their cute "smiley face"-looking syntax. I'm only about 10 years late in editing this reply to mention very useful fact ;-)
Original reply c. 2009 (assumed XPATH 1.0)
No, the XPATH syntax doesn't allow to embed comments within the path string.
This is typically not a significant limitation because paths are usually short and a comment can be placed nearby, in the particular syntax of the host language (XSLT, C#, whatever...)