Hey @ppx80, I got some ideas to improve the lib. Up to you to decide whether some may fit into it. Good work so far anyway!
- Since you fire raw SQL commands, you don't really care about the
DbContext. In my opinion you could have let the user pass the SqlConnection (or connection string) through the factory method, making the library suitable for a "much broader" audience (not having the dependency to EF).
- You could even allow passing the connection directly, without the factory, since you are not managing it and in the current implementation the same connection is used for all "steps" anyway.
- Return a detailed custom exception with explicit properties that tell you which records where updated and at what point it did break. It would help retrying without needing to re-read.
- I would love to have a convenient way to set different values for the same field. Let's imagine I have to update the status of a bunch of orders, but they are not gonna be all the same.
Possibility 1: An overload of the Set method where I can pass a value provider: .Set(o => o.Status, key => _completedOrders.Contains(key) ? OrderStatus.Completed : OrderStatus.Processing). Of course this would make it more complex for you, since you then have to figure out how many statements you need to generate.
Possibility 2: A slightly different API where you allow multiple For to be chained.
var update = BHulk<Order>
.UseContext(() => ContextFactory())
.For(Enumerable.Range(1,5000), x => x
.Set(o => o.Status, OrderStatus.Executed)
.Set(o => o.ModifiedDate, DateTime.UtcNow))
.For(Enumerable.Range(5001,10000), x => x
.Set(o => o.Status, OrderStatus.Pending)
.Set(o => o.ModifiedDate, DateTime.UtcNow))
.InStepOf(1000);
These are just two ideas, there may be better ones.
...more to come... ;)
Hey @ppx80, I got some ideas to improve the lib. Up to you to decide whether some may fit into it. Good work so far anyway!
DbContext. In my opinion you could have let the user pass theSqlConnection(or connection string) through the factory method, making the library suitable for a "much broader" audience (not having the dependency to EF).Possibility 1: An overload of the
Setmethod where I can pass a value provider:.Set(o => o.Status, key => _completedOrders.Contains(key) ? OrderStatus.Completed : OrderStatus.Processing). Of course this would make it more complex for you, since you then have to figure out how many statements you need to generate.Possibility 2: A slightly different API where you allow multiple
Forto be chained.These are just two ideas, there may be better ones.
...more to come... ;)