Separate element type from primitive collection #31677
Conversation
|
/cc @roji I haven't changed any places in query to call |
To allow mapping types like ranges, which have an element type, but don't behave as collections.
ajcvickers
force-pushed
the
230910_ItsAHorse
branch
from
ee4b708 to
11fb3ae
Compare
|
@ajcvickers I'm not sure I'll actually be introducing non-collection mappings which make use of the core "element type mapping" concept... The core concept really is about unlocking queryability (composing LINQ operators), so non-queryable types don't really have anything to gain by using this over simply having a provider-specific reference to their "element" type... But regardless of that, yeah, we should do a quick pass and change places where we currently look at the element type mapping instead of the property. The relevant ones are probably this one in nav expansion, and this one in translation, if you want to just change them in this PR. Note that for ranges specifically, I'm thinking that it may actually be possible (and useful) to introduce queryability for some of these: see npgsql/efcore.pg#2867. |
|
(leaving it to @AndriySvyryd to review these metadata changes) |
|
(ah, I see this is partially done in https://github.com/dotnet/efcore/pull/31680/files#diff-6c8d087179e9bd9496dd5122b69f7ccffa83e5b4b191862cecb14ca840ef69bcR2313 - consider also doing the nav expansion change there) |
|
|
||
| SetAnnotation(CoreAnnotationNames.ElementType, elementType); | ||
|
|
||
| IsPrimitiveCollection = ClrType.TryGetElementType(typeof(IEnumerable<>))?.IsAssignableFrom(clrType) == true; |
There was a problem hiding this comment.
Make this a parameter to avoid duplicate logic (it will require generating different code for compiled model though)
There was a problem hiding this comment.
Compiled model isn't currently working for primitive collections anyway. I'm starting to look at it.
To allow mapping types like ranges, which have an element type, but don't behave as collections.