In one of my current projects I heavily rely on Table Storage bindings used in many of my functions. In fact I have several dozen API functions, which are the base of the whole system. Because codebase grows each day, I needed a tool, which will allow me easily validate whether I query Table Storage correctly – that means I follow some basic principles like:
using both PartitionKey and RowKey in a query
if RowKey is unavailable – using PartitionKey so I won’t have to read the whole table
using $top whenever possible so I won’t load the whole partition
using query projection – leveraging $select for selecting only a subset of columns in a row
In fact I knew two ways of doing that:
Checking logs of Storage Emulator, what I described in this blog post. The disadvantage of that solution is that is logs nearly each and every request so it is hard to find a particular one you’re interested in
Using SQL Server Profiler to check what kind of queries are materialized
I needed a tool, which would combine features of both solutions.
Reading SQL Server Profiler
The idea was to somehow read what SQL Server Profiler outputs when queries are sent to Storage Emulator. Fortunately it is really simple using following classes:
Both are easily accessible in SQL Server directory:
There is however a small gotcha. Since SQL Server Profiler is a 32-bit application, you cannot use above classes in 64-bit one. Additionally those assemblies are SQL Server version sensitive – locally I have an instance of SQL Server 2017, if you have other version, you’d have to change the path to point to the correct one.
Does it work?
After some initial testing it seems it works. Let’s assume you have following code: