1 2 3 |
|
It looks nothing wrong with the above code at the first glance. Let’s have an interesting experiment,
1 2 3 4 |
|
As you can see, the DateTime.now.utc
returns “12:35:50”, while the SQL statement in the first line says “12:00:16”, there’s a mysterious gap between two of them. Actually, the “12:00:16” is the time I started the rails console, to be more precise, it’s the time the app/models/invitation.rb
is loaded, it’s the time the DateTime.now
in the expired
scope was evaluated. This could be a serious problem for some of you, espeically under production environment, since once you deployed your application, the DateTime.now
will keep what it was when the application was fully loaded by the application server, and it will be a constant value instead of a variable value as you imagined, the only chance it will get changed is the next time you deploy the application.
The problem seems to be mysterious, but the solution to the problem is pretty straightforwarding, lambda
, have lambda
work with the scope will make the statements in the closure evaluated dynamically every time the scope is called.
1 2 3 4 5 |
|
1 2 3 4 |
|
It seems to be working this time. It’s time to add more spec to cover this.
1 2 3 4 5 6 7 8 9 10 |
|
The above test will fail if you not using lambda
, just keep in mind, test will save your ass every time.