Remove hardcoded references to id and created_at fields

[jrmehle]

The gem assumes the generated migration is run without modification and refers to id and created_at fields throughout.

The first two commits change the version model to use the class' primary key instead of referencing id directly.

The last commit adds a configuration option for "timestamp_field" which allows the user to specify the name of the field which is used to track when the version was created.

[airblade]

Thanks very much for this, much appreciated.

Please could you add a test for the custom timestamp field?

[jrmehle]

I'm a bit lost as to how to go about testing this feature. I've tried setting the value in the test app and then checking for it, but that breaks other tests.

[airblade]

Sorry about the delay getting back to you. I hope it hasn't inconvenienced you.

I added a test for the timestamp field here.

Your changes are in v2.6.1. Thanks again!

[jaredbeck]

The last commit adds a configuration option for "timestamp_field" which allows the user to specify the name of the field which is used to track when the version was created.

@jrmehle Why was this necessary? Was there some reason your app had to change the name of the column (versions.created_at)? The standard column name in rails is created_at. Furthermore, the versions table is an implementation detail of PT. Yes, parts like object_changes are configurable, and we want people to be able to add metadata columns, but I see no reason to make the name of the created_at column configurable. It adds unnecessary complexity to PT. Unless there is a good reason why it has to be configurable, I would like to simplify PT by deprecating this configuration option. Please advise.

[jrmehle]

Yeah, it was necessary. The reason it was added was because at the time I was working for a company with a legacy, non-standard Rails database that did have timestamp columns, but happened to have named them differently than Rails would expect. Anyone working in this sort of environment is going to benefit from this change. While I do not work for this company any longer, I can't give my blessing to this change.

[jaredbeck]

Thanks for the quick response, Jared.

.. a legacy, non-standard Rails database that did have timestamp columns, but happened to have named them differently than Rails would expect.

Why were they named differently? If they were forced to use the standard name in the versions table only would they be able to?

[jrmehle]

Consistency. Every other table in the database conformed to the same naming scheme for timestamp fields. Sorry, I can't really answer what the company I left almost 2 years ago would do. At the time, the deal was, we conformed to existing company database standards. I can imagine that other such scenarios exist within organizations. Again, I therefore cannot recommend you go forward with your change.

[jaredbeck]

Thanks Jared, that answers my question. If I understand correctly, there was no technical reason why that company couldn't use the standard rails timestamp name. I'm going to recommend that we simplify PT by requiring people to follow the rails convention. I'll discuss it with Andy and Ben in #861 and I'll make sure to mention your recommendation there as well. Thanks again for your quick response.