Fix #246 -- Add support for deepcopy

[vchrisb]

this PR should fix #246

With Django 2.2 being EOL in April 2022, deepcopy support is only fixed for Django 3+

[codecov]

Codecov Report

Merging #265 (312f73f) into master (90cf8de) will increase coverage by 0.15%.
The diff coverage is 100.00%.

❗ Current head 312f73f differs from pull request most recent head ff55581. Consider uploading reports for the commit ff55581 to get more accurate results

@@            Coverage Diff             @@
##           master     #265      +/-   ##
==========================================
+ Coverage   97.40%   97.56%   +0.15%     
==========================================
  Files           5        5              
  Lines         270      287      +17     
==========================================
+ Hits          263      280      +17     
  Misses          7        7              

Impacted Files	Coverage Δ
stdimage/models.py	96.90% <100.00%> (+0.29%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 90cf8de...ff55581. Read the comment docs.

[codingjoe]

Thanks, @vchrisb, to be honest. I am going to need a minute to review this. Django does a lot of magic here to avoid issues with the file objects when coping them. Copying the whole dict seems to break this again. Would you be so kind as to share a little more information about the exception and the error you are seeing in your setup in the issue description? That would help me a lot to identify the best solution. Thanks, Joe

[vchrisb]

There is no exception itself while executing setUpTestData() but the deepcopied objects used in the test cases are missing the variations. And therefore testcases trying to access the variations will fail.

From my understanding, deepcopy is using the attributes of the StdImageFieldFile Class to generate the list of attributes to be copied. But due to the variations being dynamic, deepcopy does not know that these need to be copied.
By adding __getstate__, called by deepcopy, it does return the list of attributes for the instance, rather for the class.
Actually deepcopy is using pickle, which is calling __getstate__. https://docs.python.org/3/library/pickle.html#pickle-inst

You can look at provided test case and run it without the addition of __getstate__.

To further clarify, it looks like deepcopy never worked with django-stdimages on any Django Version, but only the changes to setUpTestData() in Django 3.2 surfaced the issue.

I don't know why deepcopy still fails with django 2.2, but with it being EOL very soon, I did not further look into it.

[vchrisb]

oh, self.__dict__copy() is actually not needed. Returning it directly is also fine:

    def __getstate__(self):
        return self.__dict__

and maybe relevant:
https://github.com/django/django/blob/main/django/db/models/base.py#L571

[codingjoe]

Thank you, @vchrisb, for the explanation and for your endurance. I just did a quick review and noticed that Django has some intriguing behavior in the super class.

[vchrisb]

@codingjoe I spend some time on it again...
Would the following be ok for the __getstate__ ?

    def __getstate__(self):
        state = super().__getstate__()
        for variation_name in self.field.variations:
            variation = getattr(self, variation_name)
            variation_state = variation.__getstate__()
            state[variation_name] = variation_state
        return state

Still struggle with unpickle using __setstate___ though.
I did not yet find a way to unpickle the variations back to ImageFieldFiles.

[codingjoe]

Yes, thank you, @vchrisb. This looks excellent! 🥇