Ryan Emerson, was the customer seeing this I/O limit problem because the query is effectively fetching all revisions for all entities of a particular type from the audit database without any further refinement?

I could understand one applicable use may be to replicate audit data into some analytic or external system and the ordering would be overhead. But from the general purpose use of this query, the default ordering is there to make sure that users who are interested in specific revisions of an entity get the data in some logical order.

That aside, I don't find the null approach to be a viable solution. I would argue that a better approach would be to extend the forRevisionsOfEntity method with another version that allows passing a boolean to disable the default ordering mechanism. This keeps the API contract clean, doesn't violate or have any negative side affects with the ordering api and keeps code fully backward compatible with existing uses.

Thoughts?