Question

I am new to dapper and plan to use it on my new project. After reading it, seems like the only problem I might have is ConcurrentDictionary.

Dapper caches information about every query it runs, this allow it to materialize objects
quickly and process parameters quickly. The current implementation
caches this information in a ConcurrentDictionary object. The objects
it stores are never flushed. If you are generating SQL strings on the
fly without using parameters it is possible you will hit memory
issues. We may convert the dictionaries to an LRU Cache.

How do I avoid this problem? Can someone please show me some code tell me how and when to flush it?

Answer 1

Per the comments up top, here’s an example of on-the-fly:

var builder = new StringBuilder();
builder.AppendLine("SELECT Foo FROM Bar");
if (fisrtName != null || lastName != null)
    builder.AppendLine("WHERE");
if (firstName != null)
    builder.AppendLine("    Bar.FirstName = @Firstname");
if (firstName != null && lastName != null)
    builder.Append(" AND");
if (lastName != null)
    builder.AppendLine("    Bar.LastName = @LastName");
var sql = builder.ToString();

As you can see, the actual SQL that dapper will now run will be different based on whether or not firstName and/or lastName are null. If both are null, you get one SQL string. If only firstName is not null, you get another. If only lastName is not null, you get yet another. And finally, if both are not null you get a fourth permutation.

This is what is meant by “on-the-fly” — dapper will cache based on these unique permutations, and given a more complex scenario, it is easy to see how you’ll end up with a great many different permutations, all of which would need to be cached independently.