Select to view content in your preferred language

Arcade's FeatureSetBy Functions: Needs an optional SQL parameter

637
1
11-06-2022 04:01 PM
Status: Open
Labels (3)
JustinReynolds
Regular Contributor

Request

Add sqlExpression as an optional parameter to the featureSetBy Aracde functions to help the performance of the form.  Making it optional makes it backwards compatible as well.

New Parameter

  • sqlExpression (Optional) Text - The SQL92 expression used to filter features in the layer. This expression can substitute an Arcade variable using the @ character.

Discussion

Pretty standard workflow is to get a feature set (currently must get all records).  Then use the Filter() function to drill down to a subset of features.  Then loop through the features to get access to a particular feature.

It is pretty easy to get the form into an odd state, where the form behaves unpredictably or becomes altogether unresponsive, even with the current options to limit the number of fields and not returning geometry.

When using these functions in a popup the calls happen once, but in a form each call happens every time the form state changes... that might a 100+ times per edit session.  If you have 10 fields fetching data that is a 1000+ calls for data.  The number of calls might be necessary, but does the client need all 100,000 records every time it makes a call just to get down to 1 record?

There may be something else at play here as I imagine leaving this out was a conscious decision in the first place.  Is there are reason we wouldn't want the initial filter to be performed server side so that the client just had a subset of data to work with from the get go?

I have a more advanced workflow to reduce the shear number of calls for data in the event that multiple fields are fetching data from the same source & feature.  In the example above, say all 10 fields need different data from the same feature, then I have an 11th field that fetches the data and returns all the fields needed by the others as a JSONified string.  Then the 10 other fields just parse the JSON for what it needs rather than making their own calls.  This way, per form state change, only 1 call external dataset is called rather than 10.  While this helps tremendously, my forms are complicated enough and the external datasets are large enough the the performance hit is noticeable in both AGOL & Enterprise.

Note:
There is a similar request in ArcGIS Online ideas that was submitted early this year revolving around popups. This was before form calculations in ArcGIS Field maps really got going.  I want to give it a bump and provide some context within form calculations.  You can find it here.

1 Comment
DougBrowning

I am still playing with this and have had some luck pushing the field I need into an array like

tbl = FeatureSet(oneField)

var arr = []

for i in tbl

      Push(arr, tbl.oneField)

Then you can loop and test on the array using Includes  vs a FeatureSet.  Not sure on your workflow but it worked for our use case.  

I would really love to hear from Esri on the best way to loop like this and which items are in browser memory and which are calls to the service.  But I cannot find anything like this in the help.  I sent it to someone on the AGOL team but no word back yet.

Can you use IsEmpty or DefaultValue so that it only runs once?  

Please report back anything you find.  thanks