In the “hey, you cant know everything” category….

A client asked me a question today about mapping TimeSpan to the Time data type in SQL Server.

I didn’t know there was a Time data type in SQL Server. I’m well aware of the Date data type we got in SS2008, but I skipped right past that other new type.

Since I never worked with a Time data type, I never had occasion to use it with EF. So when my client said something about timespan, I thought “that can’t be right”. Timespan is about intervals, not a point in time. Then he said something about the DateTime.TimeOfDay property which returns a timespan and I was all

So….

step 1:create a table in a SQL Server Database that has a Date field and a Time field.

step 2: reverse engineer to code first (I used the EF6 designer)

  public partial class SeparatedDateTime
    {        
        public int Id { get; set; }

        [StringLength(50)]
        public string somestring { get; set; }

        [Column(TypeName = "date")]
        public DateTime justDate { get; set; }

        public TimeSpan justTime { get; set; }
    }

ok so there it is: TimeSpan

step 3: write some code to test it out:

    private static void InsertSeparatedDateTime() {

      using (var context = new DateTimeTester()) {
        context.SeparatedDateTimes.Add(CreateSepDT());
        context.Database.Log = Console.WriteLine;
        context.SaveChanges();
      }
    }

    private static SeparatedDateTime CreateSepDT() {
      var sepDT = new SeparatedDateTime();
      sepDT.somestring = "A Test";
      sepDT.justDate = DateTime.Now.Date;
      sepDT.justTime = DateTime.Now.TimeOfDay;
      return sepDT;
    }

step 4: debug. 

check sepDT.justTime value and it looks like this : it is the milliseconds since midnight in many flavors

The log shows me that EF has transformed that value into a time value for the insert:

And surely it does the opposite when reading that data back out of the database.

Some caveats:

• 24 hr time only

• Presumes you calculated that timespan value correctly

• All caveats associated with UTC

TLDR:
For EF7 Beta 4 (via nuget) the package you want is Remotion.Linq 2.0.0-alpha-002.

I recently updated some demos from using the EF7 stable (stable comes from Nuget.org, not the nightly build package source) version beta3 to beta4. It involved updating a lot of other packages and I know enough to be dangerous so this took me a while.

But I got it worked out and everything compiled and everything ran correctly …or so I thought.

There was a test I missed running which performed some LINQ queries.

I tried to demo that at in a conference session earlier this week at Techorama and it threw an exception. Rather than struggling with it, I assured the attendees that I knew this worked and was probably a versioning issue. I finally got a chance to dig into that today and have solved the problem.

It was indeed a version issue. I found a GitHub issue that indicated this problem was caused by having the wrong version of Remotion.Linq installed. But the conversation was based on an earlier build of EF7 and wasn’t sure which version of Remotion.Linq.

But in fixing the problem, I targeted the wrong version for an update, thinking the “stable” build might be what I wanted since the EF7 betas in nuget are considered “stable” betas. Unfortunately trying to install that stable version (1.15.15) caused nuget to hang for so long I had to just crash visual studio. I tried this repeatedly from different angles so I wasted over an hour being a dummy.

When I finally decided to try the 2.0.0-alpha-002 installed, it updated quickly and easily and my LINQ queries executed successfully.

I am updating some demos I created earlier in the year and using the Beta4 version of EF7 that is the latest stable beta and available on Nuget as opposed to the super-bleeding edge APIs you can get via the nightly builds source.

There were some API changes to features I was using and I had to do a bit of exploring to sort them out so wanted to share in case you are doing the same.

Keep in mind that there are a LOT of things that have evolved between these two versions. I’m just focusing on the things I had to change so that my little demos continued to work properly.

AttachGraph

DbContext.ChangeTracker.AttachGraph is now DbContext.ChangeTracker.TrackGraph.

Here’s an example of it in use with a graph of all new objects and the root of the graph is newSamurai.

context.ChangeTracker.TrackGraph(newSamurai,
          e => e.State=EntityState.Added); 

DbContextOptions

DbContextOptions is now DbContextOptionsBuilder.

You’ve most likely seen this used as a parameter in the OnConfiguring override for DbContext.

Here is the original signature:

protected override void OnConfiguring(DbContextOptions options) {}

Here is the new signature:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { }

DbContext/DbSet.Add Overload for Ranges

EF6 has DbSet.AddRange. Originally EF7 switched the functionality to be an overload of Add which was cool but not backwards compatible so we’re back to DbContext.AddRange and DbSet.AddRange.

DbContext.Entry.SetState( )

The DbContext ChangeTracker API since EF4.1 let us set state with

DbContext.Entry.State= EntityState (where EntityState is an enum)

EF7 started out with a nicer API for this which was

DbContext.Entry.SetState(EntityState)

But for the sake of backwards compatibility, it’s now back to

DbContext.Entry.State=EntityState

That’s what I’ve encountered so far. Hope it helps