The field _could_ be used with null=True #62

Activity

1. aweakley

   self-assigned this

   on Jun 13, 2024
2. aweakley

   added 2 commits that reference this issue on Jun 13, 2024

   Anticipate None for date_display #62

   9529491

   Merge pull request #63 from ixc/62_field_could_be_none

   ...

   630a165
3. ColeDCrawford commented on Jun 13, 2024

   

   ColeDCrawford

   on Jun 13, 2024

   Contributor

   More actions

   Somewhat related: I updated a project that was using EDTF v4 to test out the v5 branch and hit this error:

     File "<...>/site-packages/edtf/fields.py", line 123, in update_values
       direct_input = getattr(instance, self.direct_input_field, "")
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   TypeError: attribute name must be string, not 'NoneType'
   

   This is because I didn't have a direct_input_field defined. Is it reasonable to assume that implementers will have that field, or should we update the fields.py to handle this more gracefully? We should at least call it out in the readme and release notes.
4. aweakley

   added 2 commits that reference this issue on Jun 27, 2024

   WIP adding checks for edtf field aliases #62

   2dee3d0

   Tests for aliases that point to non-existent fields #62

   1a5ebd5
5. aweakley commented on Jun 27, 2024

   

   aweakley

   on Jun 27, 2024

   MemberAuthor

   More actions

   I've made a PR #68 to add some Django checks for the field.