DataScope.CommitChangesAsync has no overload to accept a Func<>

Posts   
 
    
yowl
User
Posts: 266
Joined: 11-Feb-2008
# Posted on: 31-Mar-2021 20:59:29   

HI,

LLBLGen Pro 5.7.2 Adapter. It looks like if you want to use the CommitChanges method of DataScope in a client server setup, i.e. with the CommitChanges(Func<IUnitOfWorkCore, bool>) then you have to use the sync version as from the screenshot, you can see there is no async.

Is that intentional?

Thanks,

Attachments
Filename File size Added on Approval
noasynccommitchangesfunc.png 10,625 31-Mar-2021 20:59.41 Approved
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 01-Apr-2021 09:44:48   

Yes, as there's no 'async' action in the call that will 'wait' on an io completion port for instance. All CommitChanges(func) does is produce a unit of work object, where no async methods are called so having that as an 'async' method doesn't help: there's no async operation in play. The Uow produced by the func you specify then has to be transported to the service, and that is an async operation, but that's done after CommitChanges(func) returns.

Frans Bouma | Lead developer LLBLGen Pro
yowl
User
Posts: 266
Joined: 11-Feb-2008
# Posted on: 01-Apr-2021 15:11:35   

I see. Perhaps my question should therefore be, why isn't there an overload that takes

CommitChanges(Func<IUnitOfWorkCore, Task<bool>>) 

Because according to the docs "The func passed in should be a method call to a method which does the actual commit action of the Unit of Work, e.g. by passing it to a service or tier" . So the func will make a call to a webapi for example and that will be asynchronous, therefore the bool return of success will be known asynchronously.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 02-Apr-2021 09:14:30   

I'm sorry, I should have looked at the docs better before replying. flushed

It's indeed the case that the passed in func performs the commit action. You indeed raise a good point, it should be there. I checked if you could add the method yourself but there's 1 private method you need to call which is inaccessible for overriding code, so it's a bit problematic.

I'll add it to 5.8.1, which we'll ship later today (as EF Core 5 + FB is now available). I'll report back in this thread when it's available.

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 02-Apr-2021 10:06:03   

We've released v5.8.1 hotfix which now contains the method:

/// <summary>
/// Async variant of <see cref="CommitChanges(System.Func{SD.LLBLGen.Pro.ORMSupportClasses.IUnitOfWorkCore,bool})"/> 
/// </summary>
/// <param name="commitUnitOfWorkFunc">The func which is called to commit the work in the Unit of work which is passed into the func by 
/// CommitChanges. The func specified has to be an async lambda. The func also gets passed the cancellation token passed to this method</param>
/// <param name="cancellationToken">The cancellation token, which is passed to the commitUnitOfWorkFunc</param>
/// <returns>the result returned by commitUnitOfWorkFunc after it gets called with the Unit of Work to commit</returns>
public async Task<bool> CommitChangesAsync(Func<IUnitOfWorkCore, CancellationToken, Task<bool>> commitUnitOfWorkFunc, CancellationToken cancellationToken)

You should use this method to perform the commit action asynchronously. The cancellation token passed to the method is passed to the func as cancellation token, so you don't need to embed that in the func. Hope this helps, and again sorry for the confusion/inconvenience, we totally overlooked the requirement to have this one async as well (we did add an async variant for the other commitchanges method)

Frans Bouma | Lead developer LLBLGen Pro
yowl
User
Posts: 266
Joined: 11-Feb-2008
# Posted on: 02-Apr-2021 17:52:58   

That's amazing. Thanks for the super fast update.