I'm trying to configure a custom picker on a large dataset, ~7100 values.
expression: search( ri!filter, fv!item)
data: index( ri!labels, local!matches),
identifiers: index( ri!identifiers, local!matches)
I'm trying to understand if my efforts will ever make the picker usable, or if maybe these numbers are too high and I should change approach for having my users select values.
I can provide additional information if needed.Thanks in advance.
7K values does not seem large enough by itself to be causing such stress to queryEntity. Is it a view with very cumbersome joins, or something?
I would concentrate on figuring out the QueryEntity performance gap before worrying about the custom picker. Out of curiosity, does the performance of the query operation improve significantly if you pull only a few columns, instead of the whole CDT?
What kind of nested CDT do you have? If you have a nested 1:M, this can have potential performance problems because it queries the parent data and queries for each of the children values separately: see the CDT Guidance in the documentation. Also, do you actually need the nested data in your query or can you just select columns from the parent like Mike suggested?
For the moment, I solved by editing the expression rule I posted by not performing any search if the length of ri!filter is less than 3.In our particular use case, at the moment this solution is acceptable for end users, considering both UX and performance.If there is a better method to solve the issue, please suggest and I will be happy to try!
I like that idea to only perform the search if at least 3 letters are entered! You could also limit it on the other side - for example, only return the first 20 items that match to display in the picker.
One other thing I have tried before too is to use a text field and a search button for this use case. It isn't quite as seamless as a picker, but you will ensure better performance because you only perform the search on click of the button. Plus, you can display the results in a grid, which would allow you to use paging if there are too many results.
Discussion posts and replies are publicly visible
© 2020 Appian. All rights reserved.