Allow set operations for columns that map to same store type #30400
Conversation
| /// </summary> | ||
| /// <param name="otherMapping">The other type mapping.</param> | ||
| /// <returns><see langword="true"/> if the two mappings map to the same type, <see langword="false"/> otherwise.</returns> | ||
| public virtual bool MapsToSameStoreType(CoreTypeMapping otherMapping) |
There was a problem hiding this comment.
Should this only compare the actual (string) store type name into account? There could be different mappings - including even with different CLR types - which map to the same store type.
There was a problem hiding this comment.
Never mind; I think you are right. Will re-work this. Was trying to be too clever. Always best not to try to be clever.
|
Why not just never throw that InvalidOperationException? If it proceeds and the query fails on the server because the store types aren't compatible then the user is in the same position: the query doesn't work. Currently this seems to be what is preventing set operations between, say, nvarchar(10) and nvarchar(20), which SQL Server is fine with. |
|
@roji @stevendarby Discussion is here: #16813 (comment) I'd be okay with removing this check entirely. |
|
Thanks for finding that discussion @ajcvickers. I'm also OK with removing the check. |
|
@ajcvickers @roji Ah cool! I think that would close #19129 |
|
Decision from design meeting: stop throwing in this case and let the database throw if the types are not compatible. |
|
Is there a way to tell when this will be released (included in what version)? |
|
@NetMage This PR is closed without being merged. We decided not to do this. |
|
@ajcvickers Thank you, I was referring to the design meeting decision to stop throwing in this case. I assume a new PR will have to be created to implement that decision, but the corresponding issues seem to have been closed based on this PR? |
Fixes #29020