-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for custom version association class with separate database connection #46
Add support for custom version association class with separate database connection #46
Conversation
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 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 So, looks like after this we are decoupling Version and VersionAssociation entirely. |
order("version_id ASC"). | ||
pluck("version_id") | ||
|
||
model.class.paper_trail.version_class.find(version_ids) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like this change could be a subquery instead of 2 separate queries. Any thoughts? (might be over-engineering)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sobrinho Any thoughts on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@westonganger that's intentional since Version and VersionAssociation might live in different databases.
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 |
Merged. Thanks for your contribution. |
Fixes #45