Provide method on FeatureService to get ALL the features

[mpriour]

For pre 10.1 servers this is always a minimum 2 step process

• objectIds query to get total number of features
• client side "paging" query to get the features

Min: 2 , Max: (Ceiling TotalResults/maxRecordCount) + 1

For 10.1+ servers this can be a single step for small datasets, but is likely also a multistep process

• "all" style query (ordered by objectIds); if no exceedTransferLimit then you're done
• if exceedTransferLimit, client-side "paging" queries to get the rest of the features

Min: 1, Max: (Ceiling TotalResults/maxRecordCount) + 1

see: #33 (comment)

[nixta]

@mpriour Does the 10.1+ need to be ordered by objectId?

Couldn't the steps for 10.1+ just be:

• "all" style query; if no exceedTransferLimit then you're done
• if exceedTransferLimit:
  • single objectIdsOnly call
  • remove objectIds retrieved in first call from returned set of objectIds
  • client-side "paging" queries on remaining objectIds to get the rest of the features

Or is there some reason for ordering which I've missed?

[mpriour]

@nixta If the "all" query for 10.1+ is not ordered by objectId, then you might also have to do an objectId query as well. If you do order by objectId, then you can just do where objectId > {lastObjectId} and skip the other steps.

Since you're trying to get ALL the features, then the order shouldn't really matter

[nixta]

@mpriour I think I see what you're saying, but that means that you will pass the where parameter (attributes + geometry + " AND objectId > {lastObjectId}") over and over again for each "page" of results. That seems that it would put more strain on the server. By using the approach I outlined where the second call is always an objectIdsOnly call, you only pass the where parameter at most twice.

Subsequent calls merely send a list of the next <maxRecordCount> objectIds returned from that second objectIdsOnly call (minus the ones already returned in the first call) on the objectIds parameter and don't use the where parameter at all.

[mpriour]

@nixta An ALL query won't have any attributes or geometry. If you need those then that it is just paging ( #36 ) and I would agree with you about the objectIds parameter being faster and less stress on the server.

In an all query we want all of the records in the feature service, no filtering. It may be spiltting hairs and it may not actually matter, but it seems to me that where=objectId > {lastObjectId} is probably a little faster than objectIds={list of 1000 objectIds}

[nixta]

Oh! Sorry! We'd been talking in #33 about getting ALL the features that match a query and I followed the reference from that thread to this. I'm clearly being a GitHub Rookie.

Can I just confirm then: we'd want a method to get ALL records matching a (chainable) query on a FeatureService and a separate method to get ALL records from the entire FeatureService?

[mpriour]

Yes! We definitely want BOTH of those