Hi all,
i have two question
1.can we select the dynamic operator :
for eg : if(1 ri!operator 2,"if true","if false")
where operator will belike {">=","<","=",etc..} . which user select from site
2. can apply a query filter on an aggregated column
eg:
a!query( aggregation: a!queryAggregation( aggregationColumns: { a!queryAggregationColumn( field: "zipcode", isGrouping: true ), a!queryAggregationColumn( field: "caseId", alias: "caseId_count", aggregationFunction: "COUNT" ) } ), logicalexpression: a!queryLogicalExpression( operator: "AND", filters: { a!queryFilter( field: "caseId_count", operator: "<", value: 3 ) }, ignoreFiltersWithEmptyValues: true )
Discussion posts and replies are publicly visible
Thanks for the quick response
But on the second point :
my use case i need to group them based the country's zipcode and count the number of records available on each group, then filter out the record which count more than 3.
Ah, Ok, I misunderstood. You'd have to do this in two steps. The first to get the data that has the aggregated counts, and then pass that data through another expression to extract on those with count > 3.
Think of how you'd have to do this if you implemented this in the database. Firstly you'd create a view that included a derived column called, say "CASE_COUNT" and then you'd have to run a SQL SELECT statement on that View with a WHERE CASE_COUNT > 3. Similarly you have to do this in two steps in Appian.
ok, but if on future the requirement might keep adding where ,we might also aggregate based on ip-address instead of zip code so i not sure will the single view will answering that.
It's a conundrum - a "future requirement" by definition doesn't exist - so should you even cater for it? But at the same time we (as IT professionals) know that changes happen and try to anticipate them. All I can say is that Appian is sufficiently agile that you can take the future requirement and implement faster than you could in other platforms.
For your specific example: if we go back to our "how would we do this in a VIEW?" though experiment, we'd create a different VIEW that still has the "CASE_COUNT" column but the data aggregated on Zip-code instead of ip-address, and then we would still use the same SQL statement, just pointing to the different VIEW.
In Appian it would be the same - a different aggregation instruction, followed by the same second filter expression on the data returned by the first expression.