Fixes #1332: Deep Comparison for Array-based Concurrency tokens.#1334
Fixes #1332: Deep Comparison for Array-based Concurrency tokens.#1334gathogojr merged 9 commits intoOData:release-8.xfrom
Conversation
|
@WanjohiSammy , may I interest you in this? |
|
@xuzhg, it's been a little quiet here. Maybe I can help with something? |
|
@xuzhg , @WanjohiSammy, I see you guys were busy with the |
|
@WanjohiSammy, bumping this up just in case. |
|
@anasik tests are missing. Can you add several tests for this Deep Comparison feature |
@WanjohiSammy, If there's something specific you're looking for in terms of tests, please let me know and I'll see what I can do? |
WanjohiSammy
left a comment
There was a problem hiding this comment.
I want to test and make sure that this is not a breaking change
@WanjohiSammy, makes perfect sense. Let me know if any tests are failing and I'll take a look. |
|
@WanjohiSammy are all existing build tests passing? |
|
@WanjohiSammy , are you waiting on me for something here? |
|
@habbes @gathogojr @marabooy please assist looking at this PR. |
|
Thank you @anasik for your contribution |
@gathogojr , it was a pleasure. I hope to contribute more. |
Fixes #1332
A popular convention today for concurrency check fields is to use a
byte[]field calledRowVersionwith aTimestamporConcurrencyCheckattribute.However, when using such a field, the
queryOptions.ifNoneMatch.ApplyTocall was having absolutely no effect. That's becauseApplyTowas internally usingExpression.Equalwhich is perfect for value types but doesn't fare very well against reference types or particularly Arrays.I fixed this by adding a case for arrays that, through a helper method, generates an expression that performs a deep comparison.