This is a draft, still needs to be tested.

@westonganger ping :)

@sobrinho I don't see any documentation for this. Can you write some in the readme. Then it should be easier to review.

@westonganger added a small example to README.md.

Is that what you are looking for?

This is the same as papertrail has for the version class, we have a use case like this :

class Product < ApplicationRecord
  has_paper_trail(
    versions: { class_name: "ProductVersion" }, # papertrail has this native
    version_associations: { class_name: "ProductVersionAssociation" } # this PR will add this one
  )
end

Ok looks alright. Can you also add a changelog entry for this

@westonganger added

Sorry to keep asking for more. But can you actually write one or two tests for this feature?

@sobrinho ping

@westonganger will do today or tomorrow

@westonganger can you review this again?

I had to change the implementation a little bit and I'm not 100% sure this is in the right direction.

Even if I remove the PaperTrailAssociationTracking::VersionConcern entirely, specs still passes.

So, looks like after this we are decoupling Version and VersionAssociation entirely.

Even if I remove the PaperTrailAssociationTracking::VersionConcern entirely, specs still passes.

So, looks like after this we are decoupling Version and VersionAssociation entirely.

So that should mean we would also have the option to modify VersionAssociation to connect to a new database and not have to specify it per model? (which is good/desirable)

Yes, the idea here is that version association class is a completely separate entity from the version class itself.

And if we remove the PaperTrailAssociationTracking::VersionConcern, we are still good.