Skip to content

Fix range mapping#698

Merged
roji merged 3 commits intonpgsql:devfrom
roji:fix-range-mapping
Nov 15, 2018
Merged

Fix range mapping#698
roji merged 3 commits intonpgsql:devfrom
roji:fix-range-mapping

Conversation

@roji
Copy link
Member

@roji roji commented Nov 14, 2018

Fixes #688

Note the rename from RangeMappingInfo to UserRangeDefinition... While working on this it got confusing, as RangeMappingInfo wasn't a MappingInfo in the strict EF Core sense. I've left the public-facing MapRange() method on NpgsqlDbContextOptionsBuilder, partially to avoid breaking existing code, and partially because it seems acceptable to call this "mapping" in user-facing APIs, while internally it produces a "definition".

roji added 2 commits November 14, 2018 13:05
We used to eagerly create mappings for user-defined ranges in the
constructor of NpgsqlTypeMappingSource. This was too early, and did not
have access to mappings coming from plugins, so creating a user-defined
range over NodaTime types failed.

We know create mappings for user-defined ranges late, when FindMapping()
is called.

Fixes npgsql#688
It was neither a MappingInfo nor a mapping in the narrow EF Core sense.
@roji roji requested a review from austindrenski November 14, 2018 11:08
Copy link
Contributor

@austindrenski austindrenski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation here looks good.

Would it make sense to add a test case for the pattern in #688 that triggered this?

@austindrenski
Copy link
Contributor

austindrenski commented Nov 14, 2018

I've left the public-facing MapRange() method on NpgsqlDbContextOptionsBuilder, partially to avoid breaking existing code, and partially because it seems acceptable to call this "mapping" in user-facing APIs, while internally it produces a "definition".

Would it make sense to deprecate [Obsolete] it for 2.2 and introduce one with the new terminology?

@roji
Copy link
Member Author

roji commented Nov 14, 2018

Would it make sense to add a test case for the pattern in #688 that triggered this?

It does :) We haven't yet written any tests on NpgsqlTypeMappingSource, but now's a good a time as ever to start... I'll add some testing tomorrow.

Would it make sense to [Obsolete] it for 2.2 and introduce one with the new terminology?

I'm not sure... From the user perspective they really are mapping a PostgreSQL range type (the first parameter) to a CLR subtype (the second parameter). The only issue is that this isn't a mapping in the internal EF Core sense: it does not extend TypeMapping and isn't a TypeMappingInfo either. So it may be OK to leave MapRange() for the user-facing API. Let me know what you think - I'm not 100% sure about this.

@austindrenski
Copy link
Contributor

Would it make sense to add a test case for the pattern in #688 that triggered this?

It does :) We haven't yet written any tests on NpgsqlTypeMappingSource, but now's a good a time as ever to start... I'll add some testing tomorrow.

Sounds great!

Would it make sense to [Obsolete] it for 2.2 and introduce one with the new terminology?

I'm not sure... From the user perspective they really are mapping a PostgreSQL range type (the first parameter) to a CLR subtype (the second parameter). The only issue is that this isn't a mapping in the internal EF Core sense: it does not extend TypeMapping and isn't a TypeMappingInfo either. So it may be OK to leave MapRange() for the user-facing API. Let me know what you think - I'm not 100% sure about this.

OK—keeping it as is sounds fine then. No need to churn the public API if we're really just talking about implementation details at this point.

@roji
Copy link
Member Author

roji commented Nov 15, 2018

@austindrenski I pushed some tests, please take a look.

Copy link
Contributor

@austindrenski austindrenski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great. One tiny nit to fix if you have time, otherwise merge at will.

public void By_StoreType_with_wrong_ClrType(string storeType, Type wrongClrType)
=> Assert.Null(Source.FindMapping(wrongClrType, storeType));

class UnknownType {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Could you move this down alongside DummyType?

@roji roji force-pushed the fix-range-mapping branch from a3359a7 to 2c81889 Compare November 15, 2018 19:51
@roji roji merged commit ecf8408 into npgsql:dev Nov 15, 2018
@roji
Copy link
Member Author

roji commented Nov 15, 2018

Fixed nit and merged, thanks for the reviewing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants