Is this the correct way to set the colspan value with the ternary operator?
colspan="((true && false) ? 9 : (true || false) ? 8 : 7)"
I'm not getting the exact result with this.
this is the output I'm getting.
Sorry for the outlines.
I'm expecting something like this
Note:-
columns are dynamic, which is why I need to add a ternary operator for this.
Related
Using a single JSONPath expression alone, is it possible to do some kind of 'OR' or '||' operator. For example, these two JSONPath boolean expressions work to check the severity of a log JSON file:
$..log[?(#.severity == 'WARN')]
$..log[?(#.severity == 'Error')]
But I'd like to do something logically similar to:
$..log[?(#.severity == 'WARN' or #.severity == 'Error')] //this is not correct
Is there any way to do this?
If you are using Goessner's parser, you can use the || operator within your expression as follows:
$..log[?(#.severity == 'WARN' || #.severity == 'Error')]
From the JSONPath page:
[,] - Union operator in XPath results in a combination of node sets. JSONPath allows alternate names or array indices as a set.
Try
$..log[?(#.severity == 'WARN'), ?(#.severity == 'Error')]
Edit: Looks like there is an open issue for logical AND and OR operators in which they state that the operators are not yet supported by JSONPath.
Thank you for your answers. In my use case I got it working by combining the two answers from #sirugh and #elyas-bhy.
$..log[?(#.severity == 'WARN') || ?(#.severity == 'Error')]
I have set a following expression in SSIS derived column component:
TRIM(xCOL) == "" ? (DT_STR,7,1252)xCOL : NULL(DT_STR,7,1252)
However, this fails to validate - I get the following error:
Error at PKG: For operands of the conditional operator, the data type
DT_STR is supported only for input columns and cast operations. The
expression "TRIM(xCOL) == "" ? (DT_STR,7,1252)xCOL :
NULL(DT_STR,7,1252)" has a DT_STR operand that is not an input column
or the result of a cast, and cannot be used with the conditional
operation. To perform this operation, the operand needs to be
explicitly cast with a cast operator.
What is wrong here?
Unicode - the bane of all SSIS things that you would think just work.
TRIM(xCOL) == "" ? (DT_STR,7,1252)xCOL : NULL(DT_WSTR, 7)
By default, expressions on strings have a return type of Unicode (DT_WSTR). You can prove this yourself by replacing your last expression with an empty string "". Look at at the type that the derived column is assigned as - it's a DT_WSTR
TRIM(xCOL) == "" ? (DT_STR,7,1252)xCOL : ""
The resolution then is to cast the result of the entire expression to your desired type. (I also think you have a logic issue since I'm assuming you are inspecting the trimmed string to determine if it's empty/zero length and then casting it to NULL). Also note, that if you ever do get a NULL in for your xCOL field, this will blow up.
(DT_STR, 7, 1252)((TRIM(xCOL) == "") ? NULL(DT_WSTR, 7) : TRIM(xCOL))
Source data
SELECT 'Hello' AS xCOL
UNION ALL SELECT ''
Results
Like the error says, you must explicitly cast with a cast operator.
TRIM(xCOL) == "" ? (DT_STR,7,1252)xCOL : (DT_STR,7,1252)NULL(DT_STR,7,1252)
I have an SSIS package that is hooked into a MySQL database that has a tinyint(1) field which is set to the value 4 and I'm checking to see if that value is 4 in the database because it should not change based on the incoming flat file if it is already set to 4, but it doesn't seem to be working.
It should not be updating the status because the field is set to 4 but I guess I just don't understand why the expression isn't working. I have tried all the different int types for SSIS and it doesn't matter because it always sets the status to 1. Based on a quick google search a tinyint should be an unsigned 1 byte int which is why I am casting it to DT_UI1
Incoming values from flat file the first being the product and the last being the status
"039414","*****","*****","*****","*****","*****","*****","*****"," "
Existing value from the database the first being the product and the second being the status
039414 4
I handle the status by the following derived column expression, basically if there is no value it should be 1 otherwise it should be 4
LEN(TRIM(Status)) > 0 ? (DT_UI1)4 : (DT_UI1)1
Here is the derived column expression that I'm using to set the product_status (products_status being the actual field from the database and prod_status the status from the incoming flat file):
((DT_UI1)products_status == (DT_UI1)4) || ISNULL(prod_status) ? (DT_UI1)4 : (DT_UI1)prod_status
What I'm expecting to happen is a few products should keep their status of 4 but are being updated to 1, does anyone have an idea why?
Edit:
I tried changing the expression to the following with no success.
(DT_UI1)products_status == (DT_UI1)4 || ISNULL(prod_status) ? (DT_UI1)4 : (DT_UI1)prod_status
and
((DT_UI1)products_status == (DT_UI1)4 || ISNULL(prod_status)) ? (DT_UI1)4 : (DT_UI1)prod_status
and just the base test
(DT_UI1)products_status == (DT_UI1)4 ? (DT_UI1)4 : (DT_UI1)prod_status
Solution:
I ended up casting the field in the query to an integer because it was being pulled in as a boolean instead of an int
CAST(products_status AS SIGNED)
Then changed my expression to the following and it worked as expected
(products_status == 4 || ISNULL(prod_status)) ? (DT_I4)4 : prod_status
Not sure about the precedence here, but don't you think you want extra parentheses around the condition in the immediate if:
( ((DT_UI1)products_status == (DT_UI1)4) || ISNULL(prod_status) ) ? (DT_UI1)4 : (DT_UI1)prod_status
Looks like it might otherwise return "true", which is sometimes rendered as 1.
UPDATE
Here is a link to Data Viewer which lets you see what values SSIS is assigning to the columns and helps you analyze situations like this.
Your original expression
((DT_UI1)products_status == (DT_UI1)4) || ISNULL(prod_status) ? (DT_UI1)4 : (DT_UI1)prod_status
returns a boolean. Let's assume products_status is 4 and prod_status is also set to 4.
((DT_UI1)products_status == (DT_UI1)4)
Evaluates as TRUE.
ISNULL(prod_status) ? (DT_UI1)4 : (DT_UI1)prod_status
Evaluates as 4.
Your original expression now evaluates as
TRUE || 4
Which evaluates to
TRUE
Which when you try to stick it in an integer column like products_status becomes 1.
Your first revision makes no substantive change to the evaluation chain and also returns TRUE (i.e. 1).
Your second revision is the correct formulation of the ternary operator, as is the final base test. However, it appears that ISNULL(prod_status) always returns FALSE in your case since you are explicitly setting it to 4 or 1 in your other derived column, so let's ignore your second revision and just go to your final base test.
With regards to your final base test, I would definitely:
Attach a Data Viewer before your Derived Column component to ensure that the products_status column being passed in is indeed set to 4
Set a Data Viewer after your Derived Column component to see that products_status has been set (or not set) properly;
Make sure that you properly mapped the products_status field to your database destination and not the prod_status field by mistake.
I have a question about if statement in tcl of the following code:
if {(($number == 1)&&($name == "hello")) || (($number == 0)&&($name == "yes"))} {
#do something here
}
The above code works, but if I wrote it down like this:
if {{$number == 1 && $name == "hello"} || {$number == 0&&$name == "yes"}} {
#do something here
}
It complains that the $number is expected to be a boolean, why? Is the second one not a valid expression? How to correct it?
Braces, {}, and parentheses, (), are not interchangeable in Tcl.
Formally, braces are (with one exception) a kind of quoting that indicates that no further substitutions are to be performed on the contents. In the first case above, this means that that argument is delivered to if without substitution, which evaluates it as an expression. The expression sub-language has a strongly-analogous brace interpretation scheme to general Tcl; they denote a literal value with no further substitutions to perform on it.
By contrast, parentheses are mostly not special in Tcl. The exceptions are in the names of elements of arrays (e.g., $foo(bar)), in the expression sublanguage (which uses them for grouping, as in mathematical expressions all over programming) and in the regular expression sublanguage (where they are a different type of grouping and a few other things). It is entirely legal to use parentheses — balanced or otherwise — as part of a command name in Tcl, but you might have your fellow programmers complaining at you anyway for writing confusing code.
The Specifics
In this specific case, the test expression of this if:
if {{$number == 1 && $name == "hello"} || {$number == 0&&$name == "yes"}} {...}
is parsed into:
blah#1 LOGICAL_OR blah#2
where each blah is a literal. Unfortunately, blah#1 (which is exactly equal to $number == 1 && $name == "hello") has no boolean interpretation. (Nor does blah#2 but we never bother to consider that.) Things are definitely going very wrong here!
The simplest fix is to change those bogus braces back to parentheses:
if {($number == 1 && $name == "hello") || ($number == 0&&$name == "yes")} {...}
I bet this is what you originally wanted.
Warning: Advanced Topic
However, the other fix is to add in a little extra:
if {[expr {$number == 1 && $name == "hello"}] || [expr {$number == 0&&$name == "yes"}]} {...}
This is normally not a good idea — extra bulk for no extra gain — but it makes sense where you're trying to use a dynamically-generated expression as a test condition. Do not do this unless you're really really certain you need to do this! I mean it. It's a very advanced technique that you hardly ever need, and there's often a better way to do your overall goal. If you think you might need it, for goodness' sake ask here on SO and we'll try to find a better way; there's almost always one available.
I think the error message you are getting does not mean that $number has to be a boolean (I got the message expected boolean value but got "$number == 1 && $name == "hello"").
It means that the string $number == 1 && $name == "hello" is not a boolean value - which is definitely true.
If you use curly braces in your if expression those strings are not evaluated but are simply interpreted as they are - as a string of characters.
In short: if uses a special "mini language" for its condition script — the same understood by the expr command. This is stated in the if manual page:
The if command evaluates expr1 as an expression (in the same way that expr evaluates its argument).
In contrast to Tcl itself, which is quite LISP-like and/or Unix shell-like, that "expr mini language" is way more "traditional" in the sense it feels like C.
In ($number == 1) number is assigned 1 and the comparison is made.Ex: 1==1 here output is Boolean.
But in {$number == 1 && $name == "hello"} $number is not assigned because of flower bracket $number is compared with 1 so output obtained is not Boolean.
Working in SQL Server 2008. My first stab at an SSIS script and I need to emulate some if/then conditional logic written in VB.net. I couldn't find any previous questions dealing with nested conditions in expressions and believe I'm following what I've been able to uncover via google on nested conditions in a derived column.
I'm receiving an error while attempting to use nested conditions in the derived column transformation editor. The error I'm receiving indicates that SSIS could not parse my expression. The actual exception: "Exception from HRESULT: 0xC0204006 (Microsoft.SqlServer.DTSPipelineWrap)"
Questions for which the answers might immediately answer my question (and create a new problem):
is there a nesting levels limit?
can nesting be performed in the condition1 portion of [expression] ? [condition1] : [condition2]
I'll give two snippets, the first is what I'm actually inserting, the second is a more reader-friendly version. Hopefully someone can point out my error.
Not sure that it has bearing, but please note that [BusArea] is a column derived in a previous step.
actual expression:
[BusArea] == "CCC" || [BusArea] == "NBU" || [BusArea] == "CA" ? (ISNULL([CASE_MORG]) or TRIM([CASE_MORG]) == "" ? ( ISNULL([TRX_MORG]) or TRIM([TRX_MORG]) == "" ? NULL(DT_WSTR,50) : [TRX_MORG]) : [CASE_MORG]) : (ISNULL([CASE_AGT]) or TRIM([CASE_AGT]) == "" ? ( ISNULL([TRX_AGT]) or TRIM([TRX_AGT]) == "" ? NULL(DT_WSTR,50) : [TRX_AGT]) : [CASE_AGT])
formatted for easier reading:
[BusArea] == "CCC" || [BusArea] == "NBU" || [BusArea] == "CA" ?
(ISNULL([CASE_MORG]) or TRIM([CASE_MORG]) == "" ?
( ISNULL([TRX_MORG]) or TRIM([TRX_MORG]) == "" ?
NULL(DT_WSTR,50)
: [TRX_MORG]
)
: [CASE_MORG]
)
: (ISNULL([CASE_AGT]) or TRIM([CASE_AGT]) == "" ?
( ISNULL([TRX_AGT]) or TRIM([TRX_AGT]) == "" ?
NULL(DT_WSTR,50)
: [TRX_AGT]
)
: [CASE_AGT]
)
I don't think there is any limit with nesting conditions. Even if there is one, I don't think we will reach the limit in the packages that we create handle our business processes.
You almost got everything correct. The issue with your conditional statement is that you have used or instead of ||
I copied your exact statement and pasted in Derived Transformation within a Data Flow task and got an error because the package couldn't parse the expression. I replaced all the or's with correct Logical OR (||) operator and the expression evaluated correctly.