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

Optional Value Conversions dependent on support from Database Provider #14319

Closed
ntyrrell opened this issue Jan 4, 2019 · 1 comment
Closed
Labels
closed-no-further-action The issue is closed and no further action is planned. customer-reported

Comments

@ntyrrell
Copy link

ntyrrell commented Jan 4, 2019

At present, my application uses Npgsql as the database provider for the main application. However, without wanting to run a blank database for unit testing, I would hope to use an InMemory provider instead.

When a column datatype (e.g. PhysicalAddress) is supported by one provider (Npgsql -> macaddr) but not another, it breaks testing. If a value conversion is entered (e.g.)

entity.Property(e => e.MacAddress)
.HasColumnName("mac_address")
.HasConversion(
    property => property.ToString(),
    columnName => System.Net.NetworkInformation.PhysicalAddress.Parse(columnName)
)

This works when using the InMemory provider, but not in the actual implementation.

Ideally, the conversion should be optional, used if the provider does not have native support for that type.

@ajcvickers
Copy link
Member

@ntyrrell The model can be conditionally configured with a type mapping based on provider using something like this in OnModelCreating:

modelBuilder.Entity<Blog>();

if (Database.IsInMemory())
{
    modelBuilder.Entity<Blog>().Property(
            e => e.MacAddress)
        .HasConversion(
              property => property.ToString(),
              columnName => System.Net.NetworkInformation.PhysicalAddress.Parse(columnName));
}

That being said, this made us think that configuring value converters for only one provider or another could be useful, and would be nice to do as part of #10784, which is about global conversions.

@ajcvickers ajcvickers added the closed-no-further-action The issue is closed and no further action is planned. label Jan 5, 2019
@ajcvickers ajcvickers reopened this Oct 16, 2022
@ajcvickers ajcvickers closed this as not planned Won't fix, can't repro, duplicate, stale Oct 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-no-further-action The issue is closed and no further action is planned. customer-reported
Projects
None yet
Development

No branches or pull requests

2 participants