Resolved GUID changing after SaveAsync

[raysefo]

Hi guys,

I am querying a table. If the GUID is empty in the table, I am generating new GUID and update the table. But as soon as I update and SaveAsync, the generated GUID changes interestingly. Why does it happen?

...
//Unique reference ID
                gameRequest.referenceId = Guid.NewGuid(); --> generates the GUID

                var gameRequestDto = iMapper.Map<GameRequest, GameRequestDto>(gameRequest);
                //Create signature
                gameRequest = Utilities.CreateSignature(gameRequestDto, RequestType.Initiate);

                //Add initiation request into database
                _unitOfWork.GameRepository.Insert(gameRequest);

                //Query GameBank database
                var gameBankResult =
                    await _unitOfWork.GameBankRepository.GetGamesAsync(g =>
                        g.productCode == requestDto.productCode && g.referenceId == Guid.Empty);

                //If we have exact number of games in our database, mark them!
                if (gameBankResult.Count() != 0 && gameBankResult.Count() >= requestDto.quantity)
                {
                    for (var index = 0; index < requestDto.quantity; index++)
                    {
                        var item = gameBankResult[index];
                        item.referenceId = gameRequest.referenceId; --> sets the GUID, so far no problem
                        item.requestDateTime = DateTime.Now;
                        item.responseDateTime = DateTime.Now;
                        _unitOfWork.GameBankRepository.Update(item);
                        await _unitOfWork.SaveAsync(); --> GUID changes after this
                    }

                    //Query GameBank database
                    var gameBankConfirmResult =
                        await _unitOfWork.GameBankRepository.GetGamesAsync(g =>
                            g.referenceId == gameRequest.referenceId); --> different GUID so no results returns
                    if (gameBankConfirmResult != null)
                    {
                        if (gameBankConfirmResult.Count == 1)
                        {
...

 

[jmcilhinney]

the generated GUID changes interestingly

Perhaps you could be a bit more specific. In fact, please be a lot more specific.

 

[raysefo]

When I generate GUID,

//Unique reference ID
gameRequest.referenceId = Guid.NewGuid();

gameRequest.referenceId gets E0D4FABD-A0B9-4748-BC6B-8AD76D24767B

But all of a sudden, when I SaveAsync,

_unitOfWork.GameBankRepository.Update(item);
 await _unitOfWork.SaveAsync();

gameRequest.referenceId becomes some other GUID. (eg. F992CFD0-A7AE-E911-873B-B88A60FAD6E1)

 

[NoUserHere]

You start the conversation mid-way like we just entered the room and you expect us to know what you are talking about... Please do try and put some effort into your posts before submitting and don't expect us to know what is wrong without descriptively explaining the problem. We are not mind readers, and we are not sitting in front of your screen seen what you are seen. Explain your code, and explain it line by line if it is not evident of what any such line is doing.

You will generally find when you put some effort into your question, you'll likely find the root cause of your problem, upon questioning. In most cases, most people do. Your little comments inline don't exactly add any clarity to the problem or the functionality that's broken, nor which you wish to achieve. Please elaborate.

 

[Skydiver]

As I vaguely recall in your other thread, you said you changed things so that the ID is generated by the database. To me it makes sense that if you called Insert(), and then eventually Update(), that the ID that the database generated would make it's way back to you eventually.

 

[Skydiver]

Since I'm a NoSQL guy, I typically read something SQL or Entity Framework, go think to myself "okay that was interesting" and then move on mostly flushing the details of what I read, but just keeping the gist of what the problem was. Anyway, I had to search around to find this article again:

Repositories On Top UnitOfWork Are Not a Good Idea

The Rationale It’s generally believed that by using the Repository pattern, you can (in summary) “decouple” your data access from your domain and “expose the data in a consi…

rob.conery.io

The reason why I bring this up is because of your so-called Unit Of Work that you have above that you are actually using more like yet another Repository. As pointed out in the article, a unit of work is meant to encapsulate something atomic. In your code, you seem to want two tables to be updated in what seems to be something that should be atomic, yet, you are using a unit of work instead of the operations being inside your unit of work. Another thing that is kind of telling is that your seeming need to do a database operation and get an ID back from it. Notice that Rob points out that same problem about needing the ID.

 

[jmcilhinney]

We used to use repositories and a unit of work in my office but we found that it wasn't really accomplishing what it was supposed to and it was creating other issues. The primary issue was lack of support for parallelism in EF and the use of async/await in calling service methods. We basically ended up using our EF context where we would previously have used a unit of work and the DbSets were used where repositories would have been. The logic encapsulated in repository methods became ended up in service methods. Life has been better ever since. Given that the point of EF is to encapsulate and simplify data access, it does rather render separate unit of work and repositories pointless.

 

[raysefo]

I changed my business logic, now everything works as I expected.

 

[NoUserHere]

Well that's good. I believe that was the suggestion in many of the replies you received.

Good you finally got it working now.