Db.Async.execMany throws "A command is already in progress" with NPGSQL

[MaxDeg]

I'm using Donald with NpgSQL and find out that the Db.Async.execMany is throwing exception due to parallel execution of the commands. It's not occurring every time, probably depends on execution time of the queries.
The issue is probably not reproducible with SQLite (maybe it allows multiple command on the same connection in parallel).
I found the issue with NpgSQL but I'm 99% sure the behaviour is the same with SQLServer.

Issue is coming from this line: https://github.com/pimbrouwers/Donald/blob/master/src/Donald/Db.fs#L110
I cannot think of an easy way to fix it without adding task CE (ply or TaskBuilder). None CE dependent solution should probably rely on combining continuation recursively.
I would gladly help to apply a fix for it :)

Exception:
Npgsql.NpgsqlOperationInProgressException (0x80004005): A command is already in progress: INSERT INTO ingredient_months (ingredient_id, month_id) VALUES (@ingredient_id, @month_id)

Failing code:
do!
conn
|> Db.newCommand "INSERT INTO ingredient_months (ingredient_id, month_id)
VALUES (@ingredient_id, @month_id)"
|> Db.setTransaction tran
|> Db.Async.execMany months
|> TaskResult.mapError (FailedExecutionError >> raise)

Workaround:
for m in months do
do!
conn
|> Db.newCommand "INSERT INTO ingredient_months (ingredient_id, month_id)
VALUES (@ingredient_id, @month_id)"
|> Db.setParams m
|> Db.setTransaction tran
|> Db.Async.exec
|> TaskResult.mapError (FailedExecutionError >> raise)

btw: nice library, it's super pleasant to write infra code with it :)

[pimbrouwers]

Hey Max!

Thanks a lot for reaching out, and for looking into this. I tested this type of flow against SQL Server this morning and I got the exact same result, as you suspected. In reverting to 6.2.0 (pre-taskbuilder removal) everything was kosher.

I just added an internal copy of the widely accepted task builder and pushed it out to nuget (6.2.4). More importantly, I added a test for this specific case to ensure any changes we make going forward.

[MaxDeg]

Wow super efficient :)
Thanks for the fix

[pimbrouwers]

My pleasure!

I've had a sudden change of heart though about the implementation. I think it's likely a better idea to take an explicit dependency on say Ply for example.

I think this way we get all the patches the Nino pushes out, and it makes it more clear to consumers what this thing depends on.

Thoughts?

[MaxDeg]

Yep taking the Ply lib as dependency is better to keep up to date. Once F# 6 is out we may take advantage of the new task builder from core library :)
Only downside that I could see is that Ply is not the only task builder implementation outside. But on the other hand it's the most popular. Giraffe made the switch some times ago, I don't know what you are using for Falco

[pimbrouwers]

Thanks again for bringing this to my attention Max.

Closing since adding Ply to deps.