This will not slow down every query everywhere.  It only sets an order by if there is a limit and offset and no order by on list requests.  If the primary key of a table is not indexed, we're doing something wrong.

In this case, the client doesn't want a particular order, it just wants consistent results.  If I go from page 1 to x, I expect to see all items by the time I get to x.  The way it works now, you get a completely random result.  That includes seeing one item multiple times and not seeing some items at all.

I guess I could set an order by on every query, but this seems like a nice design solution to give clients consistent results.  An API is supposed to abstract some of this stuff away from the client.  Given that we have a hard limit of 100 results on queries, a client's only option is to use paginated requests to load ALL items.  Without an order by, it's impossible to get all items with paginated queries.  You will get a random set of items, but you will not get them all.

Do we leave it up to the client to set an order by if they want consistent results (and assume that they will understand this) or do we write an API and will handle assumptions like this for the client? In my case, I'm was trying to load 5289 products from a db and only getting 3852.