Configuration for `object` and `object_changes` column names?

Is your feature suggestion related to a problem? Please describe.

I'm trying to migrate an application that has ~5 million version records from YAML to JSON to take advantage of a bunch of the quality of life features PaperTrail provides. I've gotten to the point where my schema looks like this:

  create_table "versions" do |t|
    t.string "item_type", limit: 191, null: false
    t.bigint "item_id", null: false
    t.string "event", null: false
    t.string "whodunnit"
    t.text "object", size: :long
    t.datetime "created_at"
    t.text "object_changes", size: :long
    t.json "object_json"
    t.json "object_changes_json"
  end

I have asynchronously backfilled object_json and object_changes_json so they capture the same information as the YAML, and am only writing YAML for new records. I've gotten this far by monkey patching PaperTrail.

To deploy this in a zero-downtime capacity, I have to incrementally cut over. Conventionally this is done by moving the reads over to the new column, then dropping the old column. Unfortunately, PaperTrail directly references the column names in code like:

      def object_col_is_json?
        %i[json jsonb].include?(columns_hash["object"].type)
      end

which means I can't do that. I think one possible way out is to monkey patch everywhere PaperTrail directly references these columns, but this feels like something anyone attempting a zero-downtime migration would face.

Describe the solution you'd like to build

Make all references to object and object_changes as column names parameters that could be overridden by configuration.

Describe alternatives you've considered

continuing to use YAML and ignoring a bunch of the functionality PaperTrail exposes

paper-trail-gem / paper_trail

Configuration for `object` and `object_changes` column names? #1482