[Dan-Knott]

Every other enum in the library uses lowercase member names, so these two were the odd ones out.

This is a breaking change, let me know if you would prefer we make it a deprecation instead.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.93%. Comparing base (4a9bb9d) to head (c560c6a).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #151   +/-   ##
=======================================
  Coverage   89.92%   89.93%           
=======================================
  Files          86       86           
  Lines        4147     4151    +4     
  Branches      866      864    -2     
=======================================
+ Hits         3729     3733    +4     
  Misses        338      338           
  Partials       80       80           

☔ 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.

[DanCardin]

perhaps this would be a good idea?

Suggested change

	volatile = "VOLATILE"
	class FunctionVolatility(enum.Enum):
	volatile = "VOLATILE"
	FunctionVolatility.volatile._add_alias_("VOLATILE")

that way it's not a hard breaking change but presumably linters will not understand this and produce an ignorable lint warning.

I probably would also merge as-is, it just seemed like a relatively easy way to somewhat maintain backwards compat.

[Dan-Knott]

I wasn't aware of add_alias. It would require bumping the min python version to 3.13

[DanCardin]

oh right, drat. looking at the source, it's moderately complicated but ultimately most of it seems unimportant and it could probably be hacked in. but perhaps that pushes it into the realm of not being worth it

[Dan-Knott]

Another alternative would be removing the @enum.unique decorator, then directly aliasing like this:

class FunctionVolatility(FromStrings):
    volatile = "VOLATILE"
    stable = "STABLE"
    immutable = "IMMUTABLE"

    VOLATILE = volatile
    STABLE = stable
    IMMUTABLE = immutable

[DanCardin]

mm that's true. i guess i was thinking about solutions where the option identity would be the same but in reality we're not really doing any checking/matching all over the place against the values such that the identity would be important, it's just used to render the option to sql so this also seems plausibly fine.

the rendering code would presumably just need to be made to compare against either in order to avoid rendering it when its not necessary.

I'd be happy with that option as well.