IncludeTotalResourceCount per resource configuration

[bjornharrtell]

I find myself wanting to opt out IncludeTotalResourceCount for specific resources, kind of similar to opting out of pagination for a HasMany relationship.

I suggest to introduce DisableIncludeTotalResourceCount argument on Resource attribute.

[bkoelman]

Why do you want to opt-out?

[bjornharrtell]

Rationale is a requirement that needs the count for some resources but not all.. and if unlucky, some of those resources (where count is not needed) can be against very large tables where count becomes too expensive.

[bkoelman]

But the total is needed to paginate through large sets, right? How can returning only the first page without a total be useful to consumers?

When determining the count is expensive, is that because indexes are missing? And what do you mean by 'expensive'? Is it milliseconds, seconds, or minutes? Or high memory or CPU usage?

[bjornharrtell]

In the specific case it's a bitemporal source of adresses. The requests to this large set is typically filtered to an expected low count of rows returned that can also be sorted so that the relevant hits are at top (chronological history for a specific entity). So removal of the count is more of a protection for misuse if the endpoint is hit without filter. I suppose to require the filtering in some way is the more correct way to handle that...

[bkoelman]

I agree that requiring a filter sounds more appropriate in that case. When combined with turning off pagination and #1752, the cost of counting disappears entirely.

Or producing an error when the number of rows exceeds a threshold (discouraging the consumer from using the API that way).

I'm hesitant to add a feature that cripples the usability of the JSON:API protocol itself.