feat: Add optional sqlalchemy_use_enum for dy.Enum

[Jack Oberman (jackoberman)]

Allow dy.Enum to emit sqlalchemy.Enum for to_sqlalchemy_columns when sqlalchemy_use_enum=True, with optional sqlalchemy_enum_name and column- name defaults for PostgreSQL native enum types.

Closes #354

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds optional support for generating native SQLAlchemy ENUM types from dy.Enum columns (primarily for PostgreSQL / Alembic drift detection), plus accompanying docs and tests.

Changes:

• Extend dy.Enum with sqlalchemy_use_enum and sqlalchemy_enum_name flags to emit sqlalchemy.Enum instead of CHAR/VARCHAR.
• Add tests for SQLAlchemy column/type generation and for (de)serialization/matching behavior of the new flags.
• Document how to enable native SQL enums and how enum type names are chosen.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.

File	Description
dataframely/columns/enum.py	Implements SQLAlchemy native enum mapping and naming rules.
tests/columns/test_sqlalchemy_columns.py	Verifies dialect-specific compilation/type naming and error behavior.
tests/column_types/test_enum.py	Validates matches() semantics + as_dict/from_dict for new flags.
docs/guides/features/sql-generation.md	Documents how to use the new native SQL enum feature.

[Andreas Albert (AndreasAlbertQC)]

Thanks Jack Oberman (@jackoberman) ! I think the functionality is solid, I just have a few suggestions to improve readability / organization. Let me know if anything's not clear.

[Jack Oberman (jackoberman)]

Thanks Jack Oberman (Jack Oberman (@jackoberman)) ! I think the functionality is solid, I just have a few suggestions to improve readability / organization. Let me know if anything's not clear.

Andreas Albert (@AndreasAlbertQC) Thanks for the suggestions! I apologize it took me so long to respond.

[Andreas Albert (AndreasAlbertQC)]

Thanks Jack Oberman (@jackoberman) ! Only super minor adjustments that I will just apply and then we are ready to go

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (13d9fe2) to head (ad71405).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #355   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           56        56           
  Lines         3463      3471    +8     
=========================================
+ Hits          3463      3471    +8     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

[Andreas Albert (AndreasAlbertQC)]

Jack Oberman (@jackoberman) while playing with this, I realized (thanks copilot :)) that the pattern of storing the private _enum_class member clashes with our implementations of matches etc on the column base class. We usually assume that a column is fully defined by the input arguments its constructor receives (with a few excluded ones like alias). You had introduced this private member so that you could get the default sqlalchemy names in case the user passes an enum. I now changed this such that we override sqlalchemy_enum_name manually in the constructor in this case, which really simplifies the implementation. Of course, that means that if sqlalchemy were to ever change the way it generates the default name, our implementation would differ from that. Personally, I think that that is a tolerable risk given the tradeoffs involved.

Please take a look and let me know what you think :)

[Jack Oberman (jackoberman)]

Jack Oberman (Jack Oberman (@jackoberman)) while playing with this, I realized (thanks copilot :)) that the pattern of storing the private _enum_class member clashes with our implementations of matches etc on the column base class. We usually assume that a column is fully defined by the input arguments its constructor receives (with a few excluded ones like alias). You had introduced this private member so that you could get the default sqlalchemy names in case the user passes an enum. I now changed this such that we override sqlalchemy_enum_name manually in the constructor in this case, which really simplifies the implementation. Of course, that means that if sqlalchemy were to ever change the way it generates the default name, our implementation would differ from that. Personally, I think that that is a tolerable risk given the tradeoffs involved.

Please take a look and let me know what you think :)

This is much cleaner! Very nice!

[Andreas Albert (AndreasAlbertQC)]

Thanks Jack Oberman (@jackoberman) !