Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
marksmunich
Creator III
Creator III

Best practices & precautions to be considered in moving the complex expressions(with setanalysis and alternate states) in front end to the scripting in back end

Hallo Qlik's,

I would like to move some complex expressions in the front end which comprises set analysis and alternate states in the expressions. could someone suggest the best practices or the precautions to be considered which moving the expressions to the backend in the scripting part.

Thanks

Marks.

5 Replies
sunny_talwar

Not entirely sure what you are trying to do, because set analysis cannot be used in the script, although you might be able to generate same results using if statements.

I would say that to be safe don't remove your front end expression, and create a new set of fields (as required) to try the replicate the result of the complex expression. Once you get the same output from the two methods, you can think of removing the complex expression.

HTH

Best,

Sunny

sunny_talwar

Alternate state is also a front end concept and won't be applicable in the back end of the application. So you won't have to worry about any states that you might have in your expression.

marksmunich
Creator III
Creator III
Author

I know that both work only in frontend, but i would like to move rest of the expression to the backend, so does this improve the performance ?

sunny_talwar

Yes it should help with performance, but performance benefit will mostly depend on how complicated your expression is. From my expreience, I have seen that set analysis and alternate states do not impact performance as much as Aggregate function and other calculation does.

Anonymous
Not applicable

I shall swerve your question and not answer it per se.

I believe the most important thing is the data model, and this can only be improved within the back end script as that is what creates it.  Often workarounds for a poor data model can be frigged in the front end with, dare I say it, horrendous front end expressions and abuse of facilities like Alternate States.  Some of these frigs can be really technically brilliant, but nevertheless will always be frigs to alleviate the symptoms of a poor data model.

My ethos has always been that bad symptoms should not be 'treated', but the underlying causes should be eliminated.

Set Analysis and Alternate States are both superb front end tools, so don't be adverse to using them, I certainly use them extensively.  Just never lose sight of the fact that the front end is always 100% reliant on it's back end data model.