Skip to content

Fix for fields using db_column - #139

Merged
millerdev merged 2 commits into
dimagi:mainfrom
terencehonles:fix-for-fields-using-db_column
Jul 9, 2026
Merged

Fix for fields using db_column#139
millerdev merged 2 commits into
dimagi:mainfrom
terencehonles:fix-for-fields-using-db_column

Conversation

@terencehonles

Copy link
Copy Markdown
Contributor

fixes: #95

Comment thread pyproject.toml

@terencehonles terencehonles Jul 6, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I can move these to a different PR, but I found it helpful to locally test the different Django versions. Tox also supports UV, so if you'd prefer using that then that plugin could be added, but I'm not sure if it's necessary unless the CI starts using tox (in that case tox-gh might make sense too)

@millerdev millerdev Jul 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think this is fine for now, although I have not used tox, so wonder if I will find it difficult to maintain?

The tests workflow on Github Actions dynamically builds its matrix from the classifiers list in this file. Would it be possible to do that with tox so the list of versions doesn't need to be maintained in multiple places?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Unfortunately I don't believe so unless you write a tox plugin. I did notice that generation, but I wasn't sure if that's mainly because it's in a different file and it's less likely you'll notice that two files need to change. The dynamic build isn't completely dynamic since you do have to maintain the exclusion list, but I understood what you were going for.

Tox is pretty useful, but really just being able to easily run the tests locally is pretty important when trying to verify you're not breaking things across Python/Django versions. As far as maintenance this would just be reading the Django release notes and figuring out which released versions support which Python version ranges and adding a new env_list item for each supported release and then translating the Django factor into a version range (it would be nice if that could be automatic, but it's not too hard to add)

@terencehonles terencehonles changed the title Fix for fields using db column Fix for fields using db_column Jul 6, 2026
Comment thread tests/test_cte.py
Comment thread tests/test_cte.py Outdated
Comment thread django_cte/cte.py Outdated
Comment thread django_cte/meta.py Outdated
@terencehonles
terencehonles force-pushed the fix-for-fields-using-db_column branch from bcbe4e5 to 1a5785a Compare July 9, 2026 16:35
@millerdev
millerdev merged commit ad30bf5 into dimagi:main Jul 9, 2026
20 checks passed
@terencehonles
terencehonles deleted the fix-for-fields-using-db_column branch July 9, 2026 18:22
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.

Fields using db_column are unsupported

2 participants