Fix a bug where virtual attribute are included when aliasing joined table column names

[finalwharf]

Issue

ActiveRecord 4.2 includes virtual attributes in selects with joins. This raises an error because virtual attributes are not persisted and there's no column with the name to the virtual attribute.

ActiveRecord::StatementInvalid: SQLite3::SQLException: no such column: people.county_plaintext ...

Background:

ActiveRecord 4.2 uses a slightly different implementation of Attributes API than in 5.0+. Before ActiveRecord 5, this API was considered private (although technically it wan't). In ActiveRecord 5+, the issue was fixed (by accident) because of the significant refactoring that took place in ActiveRecord and ActiveModel.

Some of the issues with virtual attributes in AR 4.2 were fixed with the addition of a new property called persistable_attribute_names. rails/rails@5383f22bb83 When checking for dirty attributes for example, they use that instead together with changed model attributes (which include the virtual ones as well).

Proposed Solution

For now we can override the column_names method of JoinPart, which the JoinDependency uses to generate aliases for the joined tables.

@FundingCircle/gdpr-engineering 👀

[h-lame]

Seems fine based on everything you mentioned at standup - removing the names of the virtual attributes from the list of columns for the model sounds exactly like the sort of solution we need. That said, I doubt I'd have the context to understand the fix if I was looking at this PR tomorrow or next week 'cos by then I'll have forgotten the details of our standup discussion. To help future investigators can we include some more details of what the problem is and how it manifests itself in the commit message or PR description. I think you mentioned that it's a bug with rails 4.x attribute API that was fixed in rails 5.x, so it would be great to include a link to that fix too if we can.

[AlexVPopov]

I echo @h-lame's notes that a reference to the relevant bug/PR/issue in Rails would good, other than that the PR LGTM.

P.S. 💯 for CreateProblems migration 😆

[finalwharf]

I've updated the PR description with a proper explanation of the issue.
I've also changed the implementation a bit (see L206)

[h-lame]

👍 on the new description; it's much clearer what's going on and will really help us if we need to come back to this.

[h-lame]

Would it make sense to only include these fixes in AR 4.2? E.g put a if ActiveRecord.version < Gem::Version("5") guard around the fix in the first commit, and around the whole file in the 2nd commit?

I know we have the guard on the presence of persistable_attribute_names but in the case of the 2nd commit we're still introducing our column_names method in rails 5 which doesn't need it at all.

[finalwharf]

@h-lame I've addressed your comment even though it will still work with AR 5+. The column_names method is delegated to base_klass, and delegate actually does module_eval(method_def, ...), so no matter if we include my patch in AR patch the method will still exist. But I understand you concern!

[finalwharf]

@elenatanasoiu please 👀