Skip to content

chore: Fix save behavior for Django 3 and drop Django 2 support #89

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

Merged
merged 29 commits into from
May 17, 2022

Conversation

bgrant
Copy link
Collaborator

@bgrant bgrant commented Mar 30, 2022

Work related to this change in Django 3:

Django 3.0 release notes | Django documentation | Django

@bgrant bgrant requested a review from dshafer March 30, 2022 22:02
@bgrant bgrant marked this pull request as draft March 30, 2022 22:02
@bgrant bgrant added the work-in-progress Work in progress label Mar 30, 2022
@bgrant bgrant force-pushed the chore/fix-saves branch from 65f966f to 4f9f49b Compare May 2, 2022 22:03
if (
ce.save_changes
and resource
and hasattr(resource, "is_dirty")
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This was a missing hasattr which allows DDA to work with models that don't use DirtyFields

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

(unrelated to Django 3)

@@ -904,10 +940,10 @@ class ResourceEndpointDefinition(EndpointDefinition):
"""

def __init__(self, *args, **kwargs):
super().__init__()
super().__init__(*args, **kwargs)
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is a fix noticed in passing (unrelated to Django 3)

@bgrant bgrant marked this pull request as ready for review May 4, 2022 15:26
@bgrant bgrant requested a review from demianbrecht May 4, 2022 15:26
@bgrant bgrant removed the work-in-progress Work in progress label May 4, 2022
Copy link
Member

@demianbrecht demianbrecht left a comment

Choose a reason for hiding this comment

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

Do we care about preserving Django and Python backwards compatibility? Given we don't have an exhaustive automated test environment I'd say that we should limit the dependencies to what we actually use (and test) ourselves. Thoughts?

"{0} instance not found".format(self.type.__name__)
)
if hasattr(self.type, "__name__"):
message = "{0} instance not found".format(self.type.__name__)
Copy link
Member

Choose a reason for hiding this comment

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

f-string would be preferred here, no? or are we concerned about preserving python backwards compatibility?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think we should try to support the versions of Python "in support", which is currently 3.7, 3.8, 3.9, 3.10.

https://www.python.org/downloads/

(so I don't care about old Python versions)

raise errors.ClientErrorNotFound(
"{0} instance not found".format(self.type.__name__)
)
if hasattr(self.type, "__name__"):
Copy link
Member

Choose a reason for hiding this comment

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

Pedantic: EAFP > LBYL (try/except over if/else)



try:
import dirtyfields
Copy link
Member

Choose a reason for hiding this comment

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

What's this about? dirtyfields is a hard requirement, no?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I was told that DDA supports models that use dirtyfields but doesn't require it. I don't know if that's true in practice.

@bgrant
Copy link
Collaborator Author

bgrant commented May 9, 2022

Do we care about preserving Django and Python backwards compatibility? Given we don't have an exhaustive automated test environment I'd say that we should limit the dependencies to what we actually use (and test) ourselves. Thoughts?

Agreed. I would ideally like to support versions of Python and Django that are currently "supported" by the maintainers of those projects, but that doesn't include Python 3.6 or Django 2.2 anymore.

@@ -9,6 +9,11 @@
import inspect
import types

try:
from django.core.exceptions import FieldDoesNotExist
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We can drop this too if we don't care about Django 2.2 compatibility:

https://docs.djangoproject.com/en/4.0/releases/3.1/#miscellaneous-1

Copy link
Member

Choose a reason for hiding this comment

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

Might bring it up in slack, but 2.2 has been dropped from official support so I'm not keen on keeping it around.

@bgrant bgrant changed the title chore: Fix save behavior for Django 3 chore: Fix save behavior for Django 3 and drop Django 2 support May 9, 2022
field_name_to_att_name = {f.name: f.attname for f in resource._meta.concrete_fields}
for k, v in resource_next._as_dict(check_relationship=True).items():
att_key = field_name_to_att_name[k]
if getattr(resource, att_key, None) != v:
Copy link
Member

Choose a reason for hiding this comment

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

Why have the check? I guess it's a performance toss-up: Is it worth writing every field every time, which would likely be less performant in cases where only one field changes vs when many fields are updated.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah - this is @dshafer's code, but that's my guess.

@@ -9,6 +9,11 @@
import inspect
import types

try:
from django.core.exceptions import FieldDoesNotExist
Copy link
Member

Choose a reason for hiding this comment

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

Might bring it up in slack, but 2.2 has been dropped from official support so I'm not keen on keeping it around.

@bgrant bgrant merged commit 40467e1 into main May 17, 2022
@bgrant bgrant deleted the chore/fix-saves branch May 17, 2022 18:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants