Why do I get this error when I'm uploading to apigee?
Both the operands for AND expression should be logical
If your condition has a single boolean term, then a relational operator operators (e.g. '==') is not needed.
For example:
<Condition>(myBoolean)</Condition>
However if you have two or more terms that comprise your condition, you then need to use a relational operator for each term, as in:
<Condition>(myBoolean == true) and (mySecondBoolean == true)</Condition>
Do you have anything more specific, like which operands?
I'd look in Conditions to see if you're trying to evaluate anything that is odd
Is it possible to do an assignment in a comparison?
Related
I am looking to understand whether or not the below functions are supported in bigquery. I have tried to use them and they are not recognized. If they are not supported, could you recommend what could be used to replace them?
ILIKE operator - case insensitive version of LIKE operator
IGNORE CASE - way to get around not having ILIKE, bigquery does not seem to support
CONTAINS operator - way to get around using wildcard operators with LIKE
Is the only way to do this with the LOWER() operator?
Thanks for the help!
BigQuery is already case sensitive so ILIKE should work with just LIKE.
For IGNORE, since BigQuery is case sensitive you have to use UPPER or LOWER in combination with LIKE. So, UPPER(column) LIKE '%BLAH%'.
For CONTAINS there is REGEXP_CONTAINS, and there is more info here: https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_contains
I have an issue with this simple query :
#Query("SELECT c FROM Cat c WHERE c.id IN (:idCat) OR :idCat IS NULL")
List<Cat> getAllCatWithOrWithoutId(#Param("idCat")List<String> idCat);
Which queried in a list, or, if the id is not mentionned, select all cats in table (idCat is optional actually).
It seems working when it's an "=" operator instead of IN but when I run the query I have the error message is : "invalid relational operator".
Even if I try with a native query.
I tried to replace idCat value by single value (it worked), or by null (it worked too), but not when I put several values.
Is it something wrong in syntax or is it simply impossible with an IN statement?
When you provide a filled list, your second part of the query (OR :idCat IS NULL) is translated to a list of values to compare to "IS NULL".
As stated on JSR-338, chapter 4.6.11, "[a] null comparison expression tests whether or not the single-valued path expression or input parameter is a NULL value", so it is not expected to support a filled list as an argument. To check lists, there is the "IS [NOT] EMPTY" expression, but it expects a collection_valued_path_expression and it is not your case.
I've stumbled sometimes with strange behavior of some persistence providers where they supported (anti-spec) this kind of comparison if you surround the parameter with parenthesis, but, again, you can not rely on it for future evolutions.
The best approach in your case would be define two different JPQLs or methods to deal with your both desired scenarios.
What are the operator precedence rules for the DB2 RDBMS engine?
I am looking for explicit rules which mention actual operators instead of precedence relations between groups of operators.
I found this document http://www-01.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/com.ibm.db2z10.doc.sqlref/src/tpc/db2z_precedenceofoperations.dita via googling, but I am looking for something that goes into more detail, e.g. precedence relations between AND, OR and NOT
If you're looking for search-condition operators, then see the Information Center section on Search conditions. Additional details are in the topic, but the basic rules are:
Search conditions within parentheses are evaluated first. If the order
of evaluation is not specified by parentheses, NOT is applied before
AND, and AND is applied before OR. The order in which operators at the
same precedence level are evaluated is undefined to allow for
optimization of search conditions.
From DB2 for z/OS 10.0.0>DB2 reference information>DB2 SQL>Language elements>Expressions>Precedence of operations
Expressions within parentheses are evaluated first. When the order of
evaluation is not specified by parentheses, prefix operators are
applied before multiplication and division, and multiplication,
division, and concatenation are applied before addition and
subtraction. Operators at the same precedence level are applied from
left to right.
I used a case in my order by and it seemed to work
SELECT * FROM TABLE WHERE KEY IN (KEY1 , KEY2) ORDER BY
CASE
WHEN KEY = KEY1 THEN 1
ELSE 2
END
I haven't check with more than 2 keys.
It's over here. Simple google could help you.
I was wondering why MYSQL uses a single equals sign in conditional statements instead of the more typical two equals signs. Is there a technical/historical reason for this? Thanks.
Hi, I was wondering why MYSQL uses a single equals sign in conditional statements instead of the more typical two equals signs. Is there a technical/historical reason for this? Thanks.
Comparison is much more common in SQL than assignment.
That's why SQL uses more short syntax to do more common things.
In classical SQL, comparison can be distinguished from assignment by context (assignment can be only in SET clause of an UPDATE statement), that's why one operator can be used for both operations.
In MySQL's extension to SQL, assignment to a session variable is denoted by :=
More like historical.
It's SQL. It has used a single equals sign for comparison since the early '70s.
There is never a case for ambiguity in SQL.
In the original A Guide to the SQL Standard by C.J.Date (1987 edition), = for assignment is only used in the SET clause of UPDATE. Everywhere else = is used it is used for comparison.
But in other languages, such as C/C++/C#/Java, = can be used as assignment but it also returns a value. So a = b means "set a equal to b, and return a" whereas a == b means "return true if a and b are equal". (This leads to a very common bug in C programs, because if (a = b) and if (a == b) are both valid, since the result doesn't have to be a bool.)
Some languages like JavaScript/ECMAScript also introduce === as a third type of comparison. In those languages, == means "convert to same type and compare" whereas === means "return true only if they are the same type and same value."
I want to be able to pass something into an SQL query to determine if I want to select only the ones where a certain column is null. If I was just building a query string instead of using bound variables, I'd do something like:
if ($search_undeleted_only)
{
$sqlString .= " AND deleted_on IS NULL";
}
but I want to use bound queries. Would this be the best way?
my $stmt = $dbh->prepare(...
"AND (? = 0 OR deleted_on IS NULL) ");
$stmt->execute($search_undeleted_only);
Yes; a related trick is if you have X potential filters, some of them optional, is to have the template say " AND ( ?=-1 OR some_field = ? ) ", and create a special function that wraps the execute call and binds all the second ?s. (in this case, -1 is a special value meaning 'ignore this filter').
Update from Paul Tomblin: I edited the answer to include a suggestion from the comments.
So you're relying on short-circuiting semantics of boolean expressions to invoke your IS NULL condition? That seems to work.
One interesting point is that a constant expression like 1 = 0 that did not have parameters should be factored out by the query optimizer. In this case, since the optimizer doesn't know if the expression is a constant true or false until execute time, that means it can't factor it out. It must evaluate the expression for every row.
So one can assume this add a minor cost to the query, relative to what it would cost if you had used a non-parameterized constant expression.
Then combining with OR with the IS NULL expression may also have implications for the optimizer. It might decide it can't benefit from an index on deleted_on, whereas in a simpler expression it would have. This depends on the RDBMS implementation you're using, and the distribution of values in your database.
I think that's a reasonable approach. It follows the normal filter pattern nicely and should give good performance.