yes, we tested by upgrading to 9.1.1 and ignored TaskType
Hi, we implemented the solution for task type successfully. However, as I previously mentioned, with approximately 20 microservices and hundreds of entities, manually configuring each one and retesting is not feasible at this stage. We urgently need a solution for this, as our deadlines are fast approaching.
Ignoring all entities affected by this issue is not a viable option. For instance, when creating a new version of an entity object, we first load the existing entity from the database, copy its details, and insert the new object into the database. Since the new version might have no direct relationship to the original entity, would this process still trigger an update to the concurrency stamp of the existing entity? We don't want to ignore the entity because we may want to trigger events when navigation properties change for that entity.
Thank you. We will try updating to 9.1.1.
Will this change in the PR(https://github.com/abpframework/abp/pull/20012/files#diff-33b18ab38146b084012e294cf1639bbce7e8cc903594b83e3beee5b49193af1f.) result in updating the modification time and concurrency stamp of all ef core tracked entities even if the navigation properties are not updated?
Hi,
I have tried upgrading v9.1.0 using abpupdate but couldn't find IgnoredNavigationEntitySelectors property. Is there a newer version where this property is available?
We have a microservices solution and heavily rely on events, so we are not confident setting PublishEntityUpdatedEventWhenNavigationChanges to false as it was defaulted to true in the previous version. Looks like the change to update the modification time came from this PR. https://github.com/abpframework/abp/pull/20012/files#diff-33b18ab38146b084012e294cf1639bbce7e8cc903594b83e3beee5b49193af1f. We don't want to disable PublishEntityUpdatedEventWhenNavigationChanges as this might impact other areas of our project.
Do you mean that when task item is inserted, task type will be modified? The following is the logs. The exception happened as the concurrency stamp got modified by a parallel request to create another task.
We have a lot of entities similar to this, so should we configure this for every entity?
The problem is we will have to disable tracking in a lot of places.
We are retrieving configuration data from the database and using it to create an entity. For instance, we query the task type from the database and utilize its configuration to create a task item and insert it. However, when we attempt to insert the task, we encounter the following concurrency exception:
There is an entry which is not saved due to a concurrency exception: TaskType {Id: 8c6fb91c-177b-d1a0-97ea-3a17acd7ce44} Modified FK {AdviceTypeId: <null>} FK {TaskRequestTypeId: c5522fb7-64df-20b1-00af-3a17acd79a32}
We have not modified any details of the task type in the API. The issue is resolved when we use IReadOnlyRepository to fetch the task type. However, given that we have numerous queries spread throughout the system, modifying them all is not a feasible solution at this stage.
Hi,
We're encountering concurrency errors when making parallel requests, even when the entity remains unmodified. Upon investigation, we found that the last modification time and concurrency stamp are updated despite no other property changes. It appears that using no-tracking queries might be the only viable solution. However, we're wondering why the SaveChanges method updates the modification time and concurrency stamp even when the entity state is unchanged. Since our queries were generated using ABP Suite, modifying all of them to use no-tracking would require significant effort, making it an impractical option at this stage. Could you assist us in resolving this issue?
Hi,
We have this issue raised by the customer that they are getting "Unauthorized" message while they are in the middle of updating some forms and they are forced to reload the page without saving the updates they made. That is the reason that we are looking for a refresh token mechanism so that they don't get the unauthorized messages while they are actively using the application.
