-
Notifications
You must be signed in to change notification settings - Fork 5
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
Allow Users to override tracker class #4
Conversation
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.
I'm not a maintainer, but as a user of this lib, I can see how this might be useful 👍🏻
I left an idea/suggestion, although it doesn't have to be implemented.
tests/models.py
Outdated
def __init__(self, *args, **kwargs): | ||
super().__init__(*args, **kwargs) |
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.
Is this doing anything? Seems like it can be removed...
tracking_model/mixins.py
Outdated
@@ -12,11 +12,24 @@ def __init__(self, instance): | |||
class TrackingModelMixin(object): | |||
|
|||
TRACKED_FIELDS = None | |||
tracker_class = Tracker |
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.
I imagine it might convenient to be able to configure the same Tracker
class project-wide, rather than setting this attribute on each models that subclass TrackingModelMixin
.
With that in mind, I would suggest a Django setting TRACKING_MODEL_TRACKER_CLASS
(or something along these lines) to set an import path for a class to use everywhere, whihc value would default to "tracking_model.Tracker"
.
However, it does make the implementation a bit more complicated. A keyword here is "imagine": it's not a problem I faced, just something I think I might need.
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.
able to configure the same Tracker class project-wide
For project-wide usage, I thought that one could easily subclass TrackingModelMixin
and override the tracking_class
and use it everywhere. (Took DRF's approach here)
But yeah, from the end user perspective, this settings approach would completely eliminate the overriding.
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.
That's actually a great solution, much simpler and direct than a setting.
Hey, thanks for PR, I will look into it shortly, seems like I don't get notifications here so sorry for late response (gotta make sure it does not happen again too). |
44d7f41
to
71181e6
Compare
Hi @sumit4613, |
Hey @drozdowsky, your changes look good to me. Please go ahead, no objections. |
Motivation
Currently
Tracker
is tightly coupled withTrackingModelMixin
, if we want to add some methods that replicate the behavior ofmodel_utils.FieldTracker
methods, we need to override theTrackingModelMixin
and rewrite thetracker
property and write a new Tracker class with the required methods.To avoid this, I'm adding a new attribute
tracker_class
toTrackingModelMixin
which defaults toTracker
.This helps us to easily override the
Tracker
and write required methods, without duplicated lines of code.@drozdowsky @browniebroke please let me know what you think about this approach.
Finally, thank you ❤️ for creating this library, it helped me solve some problems that were coming up because of
FieldTracker
.