-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: BulkMergeAsync with multiple qualifiers #864
Comments
I am shock on the number of qualifiers to only add/update such single TransationTypeId column. 😄 We will test this and will get back to you. Can you try check if this is as well failing on the |
While on my way back, I just realized that you use a NULLABLE column as part of the qualifiers. Though, this is technicaly possible, but it is highly not recommend to use it, and if it is the use-case is very low in ratio. RepoDB is using an explicit equality '=' in which would always return false to 'NULL = NULL'. I would say, this is a valid bug even though we have not yet investigated it. |
Link to the code: Line 680 in 57e44b0
|
Actually the number of identifiers is needed to identify a unique transaction, because I have to insert them only once. Source data does not expose a unique identifier for each transaction, so it's built on my side as a combination of a "minimum" amount of fields that makes the transaction unique.
I am going to test also the MergeAll operation, with an ITrace object as well. |
I see that you already identified where things go wrong, thank you. :-) This is the SQL statement generated by MergeAll and I confirm that also in this case there is a problem with (not) unique values:
|
I will issue you a hot fix beta only for the bulk operations (BulkUpdate). The fixes for the MergeAll operation will be a part of the next release. Is that ok? |
If the hot-fix will work with BulkMerge/BulkMergeAsync then it's totally fine! Thank you! |
The fix is now available at RepoDb.SqlServer.BulkOperations v1.1.5-beta1. |
I confirm that the fix is working! Thank you again. |
Thanks for confirming. 😄 |
It seems that BulkMergeAsync does not work as expected in case of multiple qualifiers. See further details below.
At every run the same records are added, even though they are already available (based on the qualifiers):
First run:
Second run:
Third run:
I am using the following call to populate the table:
where transactions is a List (coming from HashSet with a custom comparer, see below):
In order to avoid duplicates, the hashset uses this custom comparer:
the schema contains the following table:
Library Version:
RepoDb.1.12.7
RepoDb.MySql.1.1.4
RepoDb.SqlServer.1.1.3
RepoDb.SqlServer.BulkOperations.1.1.4
The text was updated successfully, but these errors were encountered: