Why it is good or bad idea to add "Change Tracking of fields" to Dapper?

user_1259620 0
Viewed 1846

We are using Dapper and Dapper.Contrib in our application. We choose Dapper because it is faster and speed is everything to us due to heavy load. And now it seems "Change tracking of fields" is vital for us. And for now Dapper.Contrib creates update query which sets all fields always and such queries make them slower. Some tables now have ~30 columns and fully updating rows in that tables are very inefficient.

As I see Dapper.Contrib has Change tracking per object, but Change tracking per field is not introduced to the library.

I did a research very carefully and find out that no work is done in that area. That luckless research confused me. I would like to hear your thoughts:

  1. If such extension is not implemented then may be it is not useful? What I am missing here?
  2. Please put yourself into my shoes. What would you do? Move to EF or introduce "Chnage tracking" to Dapper.Contrib?
  3. May be adding such feature will make Dapper slow and that's why that feature is not implemented yet?
dapper .net-core entity-framework .net c#
2 Answers

Dapper.Contrib can do change tracking if you use the Get and Update methods, and you hand Update the same object (after you make changes to it) that you retrieved using Get.

Change tracking per field is inconsequential. Change one field and you still have to write the entire record.

If you really only want to change a single field (or two...) without incurring the cost of writing the entire record, you have to do this:

conn.Execute(
    @"UPDATE MyTable SET MyField=@myParameter WHERE ID = @id",
    new { myParameter = myNewValue, id=myID });

Note: You might find support for per-field change tracking here. It's not in Dapper because:

This isn't a direction we want to go with Dapper. If you want full change tracking or updates for objects I would recommend one of the ORMs that accepts these additional costs associated with change tracking like Entity Framework. It's just not something we want in the core Dapper library. -- Nick Craver

user_1029370

Try dapper raw sql or stored procedure instead of using Contrib's update? Just see if raw sql / stored procedure is faster or not. If it's faster than contrib's update, guess you need to use raw sql / stored procedure if you are concerned about performance.

If I were you, I would switch to EF Core. It's much faster and shorter time in development.

user_127349140
Related