Yes, and its not my solution ( thanks to @erik_jan ):
If you have >1000 features (ID's) you will need to do the following:
Add a Counter starting with 0
Add an ExpressionEvaluator with floor(@Value(_count)/1000).
Add an Aggregator with group by on _result and a list _list, attribute to concatenate > values where in clause
Add a StringConcatenator to create the IN part of the WHERE clause using the
concatenated attribute attribute.
This way you get IN clauses with a max of 1000 values.
Hope this helps, it did help me countless times.
Thanks itay..That works like a charm!
My two cents to add here is it to utilize the Aggregator to concatenate the IDs (one less transformer StringConcatenator). as shown in the below snapshot. so a counter, ExpressionEvaluator, and an Aggregator can do the job.
FME rocks!
Thanks itay..That works like a charm!
My two cents to add here is it to utilize the Aggregator to concatenate the IDs (one less transformer StringConcatenator). as shown in the below snapshot. so a counter, ExpressionEvaluator, and an Aggregator can do the job.
FME rocks!
An additional tip. In this case, you can also set Yes to the Input is Ordered by Group parameter. The advantages are:
- The performance at run-time could be improved.
- The input order will be preserved as the order of the concatenated attribute values and the generated list elements.
An additional tip. In this case, you can also set Yes to the Input is Ordered by Group parameter. The advantages are:
- The performance at run-time could be improved.
- The input order will be preserved as the order of the concatenated attribute values and the generated list elements.
takashi - that option has dramatically sped up the process even!
Do you think this option has to be set to Yes by default in Aggregator?
Thanks a lot !
takashi - that option has dramatically sped up the process even!
Do you think this option has to be set to Yes by default in Aggregator?
Thanks a lot !
The option can be used only if it's guaranteed that the input features are ordered by group. Otherwise, the Aggregator cannot aggregate features as expected.
In your case, the input features are definitely ordered by group, but in general, the order of features is unknown. I therefore think it's better to set No to the parameter by default so that the features will be aggregated as expected regardless of their order.
However, if you know that features are ordered by group almost always for your job, you can set Yes to the parameter as your own default setting through the uDefaults] button in the parameters dialog. Check .Defaults] > Save as My Defaults after setting Yes to the parameter.