Make it possible to override the implicit order column

[tekin]

When calling ordered finder methods such as first or last without an explicit order clause, ActiveRecord sorts records by primary key. This can result in unpredictable and surprising behaviour when the primary key is not an an auto-incrementing integer, for example when it's a UUID. This change makes it possible to override the column used for implicit ordering such that first and last will return more predictable results.

Example:

  class Project < ActiveRecord::Base
    self.implicit_order_column = "created_at"
  end

This takes a different approach to #34236, which automatically switches to using created_at if the primary key is a UUID and a created_at column exists.

[rails-bot]

r? @rafaelfranca

(@rails-bot has picked a reviewer for you, use r? to override)

[tekin]

r? @eileencodes

[eileencodes]

Do you think it would be clearer to use UUID as the example column? Like we talked about at RubyConf created_at might not be a good column for someone to use because there could be duplicates.

What would happen in the case there are duplicates? Can we make sure that Rails orders first by the set column and second by the ID if that column isn't a unique value?

[tekin]

The particular use case for this feature is when the primary key itself is a UIID, and thus first/last return records in a seemingly arbitrary fashion because they aren’t sequential so I’m not sure if that would make things clearer. In such a case you would be able to specify the created_at as the implicit order column and thus get results that are closer to what happens with numeric incrementing primary keys. As you point out though, this would mean potentially inconsistent records being returned if the column isn’t unique and there are two with the same value. Adding a secondary sort by the primary key is one option to ensure the same record is always returned. The other alternative is to accept that if the user specifies a non-unique column they do so at their own risk. I prefer the later to keep things simple, but I’m happy to work up a patch that also includes the primary key as a secondary sort. What do you think?

[tenderlove]

Instead of doing this as a getter / setter, could we just let subclasses override?

For example, the implementation in active record is:

class ActiveRecord::Base
  def self.implicit_order_column
    primary_key
  end
end

If you want to override it in your subclass, just do:

class Project < ActiveRecord::Base
  def self.implicit_order_column
    "created_at"
  end
end

That way we don't have to deal with ivar / cache management.

[matthewd]

I think class_attribute would be better: it should be as simple as the override version, but is much more accessible for e.g. a future deprecation.

[tekin]

I did look into class_attribute but it wasn't immediately obvious how I'd set the default value to primary_key.

[matthewd]

Hmmm.. I guess you'd set it to nil, then || it in the caller

[tekin]

@eileencodes / @tenderlove any thoughts on this? should I update to use class_attribute instead?

[tenderlove]

@tekin yes, make this a class attribute and then we'll merge it. 😊

[tekin]

Updated to use class_attribute.

[tekin]

PR updated to use an overridable class method instead of getter/setter.

[eileencodes]

Looks good, thanks 👍

[tekin]

🎉