search

codeforamerica / denver-schedules-api

An api for city events & schedules.
MIT License
7 stars 5 forks source link

Fix RemindOn bug #46

Closed gregoryjscott closed 10 years ago

gregoryjscott commented 10 years ago

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.

boonrs commented 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.

gregoryjscott commented 10 years ago

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.

boonrs commented 10 years ago

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.

boonrs commented 10 years ago

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