Skip to content
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

Revisit enum/range/extension/composite mapping #1026

Closed
roji opened this issue Sep 16, 2019 · 1 comment · Fixed by #3167
Closed

Revisit enum/range/extension/composite mapping #1026

roji opened this issue Sep 16, 2019 · 1 comment · Fixed by #3167
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@roji
Copy link
Member

roji commented Sep 16, 2019

This issue centralizes mapping design decisions for some advanced PostgreSQL types/objects: enums, user-defined ranges

Current situation

  • Extensions have to be defined on the model (for migrations).
  • Enums (and theoretically composites) need to be mapped to a user CLR type. So they have to be defined once on the model (for migrations) and mapped globally at the ADO level (for ADO and also for NpgsqlTypeMappingSource)
  • User-defined ranges don't have a user CLR type (it's always NpgsqlRange<T>). They have to be defined on the model (for migrations) and in the context options (for NpgsqlTypeMappingSource).

Some issues:

Thoughts

  • We should consider having all extension and definitions as context options, like user-defined ranges. This will naturally cause different type mapping sources to be created, isolating the different databases with their different type configurations.
  • Things still need to be on the model, because that is the only thing that gets versioned for migrations. We could have a convention that creates the model entries for extensions, ranges and enums on the model based on context options. This would remove the need to double-map.
  • ADO mappings are still a problem. We could switch to per-connection mapping in NpgsqlRelationalConnection, based on the context options, but this has some perf consequences (see Speed up connection-specific mapping changes npgsql#2263). Ideally it would still be possible to do global type mapping somehow.
@roji
Copy link
Member Author

roji commented Aug 1, 2022

See #2435 (comment) for thoughts on enabling a global opt-in for PG enums and what that would require. We may possibly want to switch to a model which doesn't require up-front mapping at the ADO level.

@roji roji modified the milestones: 7.0.0, 8.0.0 Oct 15, 2022
@roji roji modified the milestones: 8.0.0, 9.0.0 Nov 13, 2023
roji added a commit to roji/efcore.pg that referenced this issue May 12, 2024
Fixes npgsql#2891
Fixes npgsql#3063
Fixes npgsql#1026

Co-authored-by: Nino Floris <mail@ninofloris.com>
roji added a commit to roji/efcore.pg that referenced this issue May 13, 2024
Fixes npgsql#2891
Fixes npgsql#3063
Fixes npgsql#1026

Co-authored-by: Nino Floris <mail@ninofloris.com>
roji added a commit to roji/efcore.pg that referenced this issue May 13, 2024
Fixes npgsql#2891
Fixes npgsql#3063
Fixes npgsql#1026

Co-authored-by: Nino Floris <mail@ninofloris.com>
roji added a commit to roji/efcore.pg that referenced this issue May 17, 2024
Fixes npgsql#2891
Fixes npgsql#3063
Fixes npgsql#1026

Co-authored-by: Nino Floris <mail@ninofloris.com>
@roji roji closed this as completed in 6b3ca68 May 18, 2024
@roji roji added breaking change Represents a breaking change and removed breaking change Represents a breaking change labels May 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant