Skip to content
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

feat: Create versioning for segments #4138

Merged
merged 31 commits into from
Jun 27, 2024

Conversation

zachaysan
Copy link
Contributor

Thanks for submitting a PR! Please check the boxes below:

  • I have run pre-commit to check linting
  • I have added information to docs/ if required so people know about the feature!
  • I have filled in the "Changes" section below?
  • I have filled in the "How did you test this code" section below?
  • I have used a Conventional Commit title for this Pull Request

Changes

This introduces versioning for segments by cloning their features into new objects and filtering out older versions of segment through a new manager class.

How did you test this code?

A few new unit tests around the models as well as updates to some existing tests to handle audit log cases.

Copy link

vercel bot commented Jun 10, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 27, 2024 3:14pm
flagsmith-frontend-preview ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 27, 2024 3:14pm
flagsmith-frontend-staging ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 27, 2024 3:14pm

@github-actions github-actions bot added api Issue related to the REST API feature New feature or request labels Jun 10, 2024
Copy link
Contributor

github-actions bot commented Jun 10, 2024

Uffizzi Preview deployment-52851 was deleted.

@github-actions github-actions bot added feature New feature or request and removed feature New feature or request labels Jun 10, 2024
Copy link

codecov bot commented Jun 10, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.60%. Comparing base (5162687) to head (70e974a).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4138      +/-   ##
==========================================
+ Coverage   96.57%   96.60%   +0.02%     
==========================================
  Files        1191     1194       +3     
  Lines       38809    39071     +262     
==========================================
+ Hits        37481    37745     +264     
+ Misses       1328     1326       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@github-actions github-actions bot added feature New feature or request and removed feature New feature or request labels Jun 10, 2024
api/segments/models.py Show resolved Hide resolved
Comment on lines 129 to 136
new_segment = Segment.objects.create(
name=self.name,
description=self.description,
project=self.project,
feature=self.feature,
version=self.version,
version_of=self,
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have clone functions in other models in the code base where we take a slightly different approach, e.g.:

def deep_clone(self) -> "Segment":
    new_segment = copy.deepcopy(self)

    new_segment.id = None  # this is what forces django to think it's creating a new model object

    ...

The benefit of this approach is that it maintains itself when new fields are added to those model classes. With the approach that you're using here, if a new field is added to the segment, we'll need to remember to add it here I think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I'll implement that strategy. Just to double check, the timestamps will still be set to now for the new model, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok this is done.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to double check, the timestamps will still be set to now for the new model, right?

Good question - I don't know. We should verify in a test. Although I guess the question is whether we want that to be the case. Since we're backfilling the history, wouldn't we want e.g. the created_at not to change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well it turns out that none of the models involved in this PR have created_at or updated_at timestamps, although they probably should, at least on the segments. Should I add them to this PR? If so, what should the default be for existing objects None or now()? Should I include conditions and rules in having timestamps as well?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add these fields to all models in the segments app, yes, but let's do it in a separate PR. Regarding the default, we could be smart and look in the objects history but that might end up being a fairly mammoth migration.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok sounds good I've made a new ticket for this.

#4211

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR is up for the timestamps:

#4236

api/segments/models.py Show resolved Hide resolved
api/segments/serializers.py Outdated Show resolved Hide resolved
@github-actions github-actions bot added feature New feature or request and removed feature New feature or request labels Jun 11, 2024
Copy link
Contributor

@matthewelwell matthewelwell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added a few more comments but I also noticed that none of the view tests actually verify that the clone is created (perhaps because they rely on the number of audit records instead, which I'm suggesting that we remove).

api/segments/models.py Show resolved Hide resolved
api/segments/models.py Show resolved Hide resolved
Comment on lines 129 to 136
new_segment = Segment.objects.create(
name=self.name,
description=self.description,
project=self.project,
feature=self.feature,
version=self.version,
version_of=self,
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to double check, the timestamps will still be set to now for the new model, right?

Good question - I don't know. We should verify in a test. Although I guess the question is whether we want that to be the case. Since we're backfilling the history, wouldn't we want e.g. the created_at not to change?

api/segments/serializers.py Outdated Show resolved Hide resolved
api/tests/integration/audit/test_audit_logs.py Outdated Show resolved Hide resolved
api/tests/unit/segments/test_unit_segments_models.py Outdated Show resolved Hide resolved
api/tests/unit/segments/test_unit_segments_models.py Outdated Show resolved Hide resolved
api/tests/unit/segments/test_unit_segments_models.py Outdated Show resolved Hide resolved
api/tests/unit/segments/test_unit_segments_views.py Outdated Show resolved Hide resolved
api/tests/unit/segments/test_unit_segments_views.py Outdated Show resolved Hide resolved
@github-actions github-actions bot added feature New feature or request and removed feature New feature or request labels Jun 21, 2024
@matthewelwell matthewelwell requested a review from a team as a code owner June 24, 2024 13:29
@github-actions github-actions bot added feature New feature or request and removed feature New feature or request labels Jun 24, 2024
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Issue related to the REST API feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants