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

Conditionally support NullBooleanField #250

Merged
merged 2 commits into from Oct 29, 2021

Conversation

ashiazed
Copy link
Contributor

Conditionally support NullBooleanField until the minimum supported version is Django 4.
It has been deprecated since Django 3.1.
This will ensure passing tests when the upgrade to Django4 happens.

Swap to using BooleanField with null=True in the tests, it has been supported since Django.2.0 and model bakery uses Django2.2 as a minimum so all is clear.

@ashiazed
Copy link
Contributor Author

I added an entry to the changelog

@@ -228,7 +228,7 @@ def save(self, *args, **kwargs):

class Classroom(models.Model):
students = models.ManyToManyField(Person, null=True)
active = models.NullBooleanField()
Copy link
Collaborator

Choose a reason for hiding this comment

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

@berinhard Since we would still technically support NullBooleanField until model_bakery no longer supports Django < 4.0, would it be okay if there were no test models with this field type? Or should there be conditional test models to make sure everything still works?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'd like to say yes but our test requirements use latest Django and as soon as we are on 4.0 we won't be able to import NullBooleanField. Should we add this as a custom field and include it that way?

Copy link
Member

Choose a reason for hiding this comment

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

I don't think we need such type of safety checks. In the past, with other deprecated fields, we did the same strategy as @ashiazed did: use ImportError and don't worry about it until bakery also drops support for that field.

Copy link
Collaborator

@timjklein36 timjklein36 left a comment

Choose a reason for hiding this comment

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

Aside from the testing consideration on which I commented, this looks good.

However, we will have to reconcile this with some ongoing work, started by @amureki, to support Django 4.0: #236.

Copy link
Member

@berinhard berinhard left a comment

Choose a reason for hiding this comment

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

This looks fine! Thanks @ashiazed!

@timjklein36 I'll merge this since you also approved the changes. About your consideration on @amureki work on #236, it's still on draft. So we can merge this PR and introduce adaptations over there.

@@ -228,7 +228,7 @@ def save(self, *args, **kwargs):

class Classroom(models.Model):
students = models.ManyToManyField(Person, null=True)
active = models.NullBooleanField()
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we need such type of safety checks. In the past, with other deprecated fields, we did the same strategy as @ashiazed did: use ImportError and don't worry about it until bakery also drops support for that field.

@berinhard berinhard merged commit cf5639a into model-bakers:main Oct 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants