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
Introduce custom type mapping for old guid literals. #584
Introduce custom type mapping for old guid literals. #584
Conversation
/// <summary> | ||
/// Initializes a new instance of the <see cref="MySqlOldGuidTypeMapping" /> class. | ||
/// </summary> | ||
public MySqlOldGuidTypeMapping() : base("binary(16)", System.Data.DbType.Guid) { } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should call the constructor that takes a RelationalTypeMappingParameters
and override the Clone
methods. This will make this mapping compatible with new EF features.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok updated. I have followed the pattern present in the other classes.
…stent with the project's other type mapping classes. Override clone methods. Introduce constructor for RelationalTypeMappingParameters struct.
@robbieknuth can you add tests for this functionality? |
@caleblloyd Yep. I just wanted to confirm that this approach is actually the right way to be doing this sort of thing (no previous experience with EF provider code) before I did that part of it. |
OK great. @AndriySvyryd has the best insight into that. I'd like to get this into 2.1.0, we will likely be looking to do another RC in 2 weeks, then a final release after that if everything checks out. |
@caleblloyd When can we expect this to be merged? |
It still does not have supporting tests, which is why it hasn't been merged yet. @robbieknuth do you plan to add tests still? |
We really need this fix merged asap since we have to do ugly workarounds now in order to deploy with this fix. @caleblloyd Could you somehow merge it? |
I went ahead and merged without the tests, could you please validate the behavior is correct in the nightly build: |
Yes it works with nightly build. When do you plan to release new version? |
The entity framework does not parameterize guids when they are put into a "IN" expression. They are generated as literals and put as a part of the SQL. This addresses issue #461 . Ultimately the fix is fairly straight forward: when using the old guid way, override the type mapping to provide an explicit implementation for the literal. I have run some preliminary tests:
Query looks like this:
schema is:
Without the fix, not oldguids:
Works as expcted. With the fix, not oldguids:
Works as expected. So this does not regress the non-oldguids case.
Without the fix, oldguids (This is the broken one):
And finally with the fix, old guids:
Hooray! it works by doing a hex literal. For sanity sake, it also works with nullable guids:
This fix also introduces a common binary formatter for the guids and the binary data type.
Select code:
Schema:
Here is it working when empty:
Note that '0x' would not be valid, so I used the X'' syntax. Binary generation with stuff in it: