You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SS provides special treatment for "CreatedOn" and "ModifiedOn" columns when it finds them in a database table. This treatment includes setting them to DateTime.Now whenever a record is created or updated respectively.
The problem stemming from this is that when these values are stored in DATETIME columns they get truncated down to whole seconds. This makes the objects which had their value auto-set differ from the logically identical objects you get from querying the database (these last ones have truncated, and hence different, DATETIME values).
Example: Class Foo models a table in the database that has a CreatedOn column and you do:
var foo1 = new Foo() { Name = "UniqueFoo" };
foo1.Save();
var foo2 = Foo.SingleOrDefault(foo => foo.Name == "UniqueFoo");
if (foo1.CreatedOn != foo2.CreatedOn) {
Console.WriteLine("Surprise!");
}
This will print out "Surprise!" with near certainty.
While this inconsistency could be considered as "why do you even bother"-level minor, it does prevent me from writing correct unit tests for projects which use SubSonic to talk to the db. Please consider pulling in this patch that fixes the issue:
SS provides special treatment for "CreatedOn" and "ModifiedOn" columns when it finds them in a database table. This treatment includes setting them to DateTime.Now whenever a record is created or updated respectively.
The problem stemming from this is that when these values are stored in DATETIME columns they get truncated down to whole seconds. This makes the objects which had their value auto-set differ from the logically identical objects you get from querying the database (these last ones have truncated, and hence different, DATETIME values).
Example: Class Foo models a table in the database that has a CreatedOn column and you do:
This will print out "Surprise!" with near certainty.
While this inconsistency could be considered as "why do you even bother"-level minor, it does prevent me from writing correct unit tests for projects which use SubSonic to talk to the db. Please consider pulling in this patch that fixes the issue:
http://github.com/defacer/SubSonic-3.0-Templates/commit/71f06697bfc41e96d1661d8e3a6d6e063fd99864
The text was updated successfully, but these errors were encountered: