-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Failing to sort owned types, when updating different combinations of fields of both parent and owned type at the same time #10568
Comments
@lakeman The exception says, |
In this case the parent type is Transaction, with a key field of Id. |
@lakeman I have not been able to repro this with just the code posted. Could you please post a runnable project/solution or full code listing so that we can easily reproduce what you are seeing? |
EF Team Triage: Closing this issue as the requested additional details have not been provided and we have been unable to reproduce it. BTW this is a canned response and may have info or details that do not directly apply to this particular issue. While we'd like to spend the time to uniquely address every incoming issue, we get a lot traffic on the EF projects and that is not practical. To ensure we maximize the time we have to work on fixing bugs, implementing new features, etc. we use canned responses for common triage decisions. |
I have been attempting to reproduce this, but I haven't been able to work out exactly what the pre-conditions are to produce a simpler test case. Looking at ModificationCommandComparer.cs; The collection of ModificationCommand are being sorted by schema, then table name, and finally the primary key of the first element of each array. It looks like this method is assuming that both of these first elements are the same EntityType. With the introduction of owned types, can these EntityType's be different? Should the sorting here compare entity types first, before assuming that they are the same? |
I've managed to trigger this reliably; |
So this seems to fix the problem;
Which I've tested by replacing the IComparer<ModificationCommand> service with a patched version in my reproducer example above. |
I'm running into this as well, after some new entities and relations were introduced. I'm also unable to exactly pinpoint the preconditions, but @lakeman's workaround fixes it (❤️ ). Stack Trace
@ajcvickers could this be considered for a 2.0 patch? |
I've been seeing another instance of this surfacing as Stack Trace (first type is an owned type of the second one)
|
The problem is related to sorting the pending changes so they can be batched together. Hitting the bug depends on the sort routine comparing two records with different combinations of types and owned types for different rows of the same table. The sort routine doesn't need to compare every pair of records to order the collection. GetCurrentValue() has different implementations depending on how each type stores the same value. So it will throw different exception types for different combinations. My reproducer above, uses a rather brute force method to fill the set of pending changes with different permutations of objects. Writing a test case for this fix probably requires passing an explicit pair of carefully constructed objects directly to ModificationCommandComparer. |
I'm not sure I really understand this problem yet....
I created an owned type to wrap every enum value, so I could save string names instead of numeric values without repeating myself too much. (Side note, this still isn't ideal as it requires each user of any enum to be more careful in how they assign a value, since an implicit cast from T creates a new instance which doesn't seem to be handled...)
The model is built by calling this extension method for every use of this type;
I can change multiple instances of this type at the same time, unless (I believe) two existing instances have been changed from the same before value to the same after value. Then I'm seeing this exception thrown;
The text was updated successfully, but these errors were encountered: