This would definitely be in the “luxury” category of features, but it popped in my head today when I was going back through my rather large app doing optimizations, now that its well past the protoype stage of development.
It would be so cool if somehow you could enable a flag, that in addition to, or along with profiling, would cause QQ to throw an exception if you are trying to `WHERE`, `ORDER BY`, or `GROUP BY` on a column that is not indexed. (Especially `ORDER BY`)
I have three major reasons why this would be useful.
1) I know that all of the indexes should have been meticulously planned out in the data model before hand, but hey, we are all guilty of oversight, laziness, mistakes at one time or another.
2) Code-genned data grids automagically let you sort on any field by clicking the column header. Unless you index every field, users can beat up the database by sorting on poorly optimized fields. The alternative is to go back and override those columns to disable sorting by default, or modify the codegen template. In that case you are making assumptions about how the users will interact with the app, which in my experience, I never 100% guess correctly. Imagine being able to cut a few users loose on the protoype and ask them to tell you what column they tried to sort on when they receive the exception for no index. It would be easy to catch the exception and print out a nice message too, something like, “Sorting on the `foo` column results in a slower query, please pass this message onto the administrator blah blah blah”. You can then mull over the feedback and decide which fields you want to index based on the performance requirements of the project. At that point you could turn off the flag, or continue to catch the exception and log it, or change the message to something like “sort on this column only if you really need to”, lots of possibilities.
3) This idea plays into the Qcodo idea of getting a protoype up and running quickly, and worrying about optimization later.