Closed gregoryjscott closed 10 years ago
If I check the db after the test is run, the correct date is in there: 7/01/2014. The issue appears to be when dapper takes the returned data and sticks it in the object. CreatedAt suffers the same issue.
It wasn't before https://github.com/gregoryjscott/denver-schedules-api/commit/2567861e68d2e47d70f9880a9952848b9406f30b and I assumed that since the tests still didn't pass that it still wasn't inserting. Looks like the only problem now is that task isn't returning a Reminder with a valid RemindOn value. It must not be reading it back from the insert statement correctly.
When I use the updated insert/select statement directly (ie in pgadmin), the select statement correctly pulls back the date. I'll look into what Dapper might be doing with that information.
If I store the query result as is, without casting to a specific object, the dates are returned correctly:
var result = connection.Query(sql, In.Reminder).SingleOrDefault();
var date = result.remind_on; // {7/1/2014 12:00:00 AM} System.DateTime
vs
var result = connection.Query<Reminder>(sql, In.Reminder).SingleOrDefault();
var date = result.RemindOn; // {1/1/0001 12:00:00 AM} System.DateTime
The
remind_on
field isn't making it into the database table. This PR currently includes tests that expose the problem - it doesn't yet include a fix. It looked like the field was just missing from the SQL, but adding it didn't fix it.I don't know if this is the cause, but the
remind_on
column is timestamp without time zone.