This Week in Rails: Time, Duration fixes and more

Posted by vipulnsward, January 13, 2017 @ 12:00 am in News

Happy new year (yet again) ! And a Friday the 13th 👻

This is Vipul, bringing you the latest from just the second week of the year, which is shaping to be really busy.

Thanks to all the 27 contributors, in particular to the 4 people who contributed for the first time. Keep up the good work!

Here are the most relevant changes to Rails master for this week.

Improved

Constant look-up would no longer fall back to top-level constant since Ruby 2.5

Since top-level constant lookup has been removed on Ruby 2.5, Rails takes care of relevant changes on its side, so that we rely on properly scoped constants, instead of relying on fallback lookup.

Fixed

Fix pool_from_any_process to use most recent specification

If a process is forked more than once, the Active Record connection pool was grabbing the oldest connection specification for a process, and not the most recent one.

This issue is not seen for single processes, but if you are forking the process multiple times, the wrong specification will be returned and incorrect connection will be used.

This change fixes the issue by reversing the list of specification names so we can grab the most recent one rather than the oldest.

Make time travel work with subclasses of Time/Date/Datetime

Previously when using time travel methods, travel_to, etc, and calling now on a subclass of e.g. Time, it would return an instance of Time instead of returning an instance of the subclass.

This change fixes the way we return the instance, so that we always return using the correct class.

Fix inconsistent parsing of Durations with both months and years

Previously the following code may fail or succeed depending on the current time.

ActiveSupport::Duration.parse(2.months.iso8601) == 2.months  
ActiveSupport::Duration.parse(3.years.iso8601) == 3.years

This change fixes the inconsistent parsing so that this comparison no longer fails.

Removed

Deprecate reflection class_name option to accept a class

The idea of class_name as an option of reflection is that passing a string would allow us to lazy autoload the class.

Using the class directly, with something like

belongs_to :client, class_name: Customer

is eagerloading models more than necessary and creating possible circular dependencies.

This option is now deprecated, pass strings of the class names instead.

Wrapping up

That’s it from Vipul . I hope you enjoyed this issue. 

If you haven’t already, start working on those RailsConf proposals, you have only 6 days left to submit a good talk!