Efcore.pg: The current CSharpHelper cannot scaffold literals of type 'NodaTime.OffsetTime'. Configure your services to use one that can.

Created on 1 Sep 2018  路  7Comments  路  Source: npgsql/efcore.pg

Having issues with time. Like so few other people I assumed Timestamp with time zone stored time zone information. Trying to correct my mistake by switching to NodaTime now. I switched all my DateTimeOffset's to Instant, and my DateTime?'s to LocalDate?'s. Creating a migration to make the change wasn't working so I just regex'ed my ModelSnapshot, Migrations and Designer files to use the appropriate type. That worked fine but running into problems trying to make a Time with time zone column so I can separately store the time of day information in Postgres. Whenever I try to scaffold a migration I get the error

The current CSharpHelper cannot scaffold literals of type 'NodaTime.OffsetTime'. Configure your services to use one that can.

Here is the model I am trying to make the migration for (with several properties omitted).
```c#
public class Event
{
public Instant Start { get; set; }
public OffsetTime StartTimeOfDay { get; set; }
public Instant? End { get; set; }
public OffsetTime? EndTimeOfDay { get; set; }
}

Saw something about it possibly being project references so here are my refs. Tried to play around with them but was unsuccessful.
```xml
  <ItemGroup>
    <PackageReference Include="AutoMapper" Version="7.0.1" />
    <PackageReference Include="AutoMapper.Extensions.ExpressionMapping" Version="1.0.2" />
    <PackageReference Include="Microsoft.AspNetCore.All" Version="2.1.2" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.1.2" />
    <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="2.1.1" />
    <PackageReference Include="Npgsql.EntityFrameworkCore.PostgreSQL" Version="2.1.1.1" />
    <PackageReference Include="Npgsql.EntityFrameworkCore.PostgreSQL.NodaTime" Version="2.1.1" />
  </ItemGroup>

Also tried switching to DateTimeOffset and using [Column(TypeName = "time with time zone")] and the migration worked but got a TimeTzHandler cannot convert to DateTimeOffset error when trying to save any entities.

I did try making a fresh solution and context and it did successfully create an initial migration with the above model even when the dbcontext was in a separate solution

Most helpful comment

For the root cause here see #575 (which is actually https://github.com/aspnet/EntityFrameworkCore/issues/8741).

All 7 comments

Took the time to make the two referenced packages netstandard2.0 . The only two packages being pulled in by ProjectReferences are the two below (one from each). Problem still persists

<PackageReference Include="Newtonsoft.Json" Version="11.0.2" />
<PackageReference Include="System.ComponentModel.Annotations" Version="4.5.0" />

Creating a migration to make the change wasn't working so I just regex'ed my ModelSnapshot, Migrations and Designer files to use the appropriate type.

Could you explain a bit more about wasn't working here?

@austindrenski When I enabled NodaTime via the optionsbuilder and tried to add a migration it had an error about the provider not supporting DateTimeOffset.

I find it difficult to believe that it was something wrong in the changes to those files since I'm able to successfully create a migration with the Instant properties but without the OffsetTime property.

Well, DateTimeOffset _shouldn't_ be supported once the NodaTime plugin is enabled, since the plugin effectively steals those mappings from the BCL types.

What I would like to narrow down is which errors occurred before you used the regex. If there are errors that cause you to _need to use_ a regex, then we should try to fix those directly. Issues arising from the regex itself will be more challenging to diagnose (though we're still willing to try).

It doesn't sound implausible that migrations after adding a plugin could be fragile, especially if type information from the pre-plugin model were required in some way. (Though this isn't the case with other NodaTime types...)

There is a known limitation that plugin adoption triggers a big bang refactor. So an error referencing BCL date/time types after adding a plugin sounds like one of the BCL type may have still been present in the model.

It would be helpful if you could provide us with:

  1. The exact error messages you encountered _before applying_ manual modifications to the migrations.
  2. A minimal reproduction of this issue, preferably in the form of a repo we can clone. This could be a simple console app with a model that includes one BCL date/time type which is then migrated to use the NodaTime plugin.

Went and consolidated my 8 migrations into 1 and that fixed the problem . And just had to do some fancy footwork with commenting out specific blocks of the migration so I wouldn't lose any data. Luckily, I was able to delete the offending table easily, because I am suspicious it does have something to do with a model snapshot of that take.

I have the branches saved so if I have any time to go figure out how it happened I'll come request that this be reopened.

@WarrenFerrell Glad to hear it worked out. Please do let us know if you end up finding the root cause, happy to reopen at that time.

For the root cause here see #575 (which is actually https://github.com/aspnet/EntityFrameworkCore/issues/8741).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

newbiecse picture newbiecse  路  4Comments

austindrenski picture austindrenski  路  5Comments

rakeshkotha picture rakeshkotha  路  3Comments

sebstr picture sebstr  路  4Comments

bikeladam picture bikeladam  路  3Comments