SQLAlchemy will be the first instance to receive those options, while evaluating the ORM model. We will need to check where it breaks down the line, and whether we can do something to improve on behalf of the dialect implementation, or if there would be a need to improve SQLAlchemy itself to support such edge cases.
Problem
Coming from those recent improvements ...
... @seut mentioned that the need to convey special CrateDB table options like that ...
... is very unfortunate from an UX perspective. I agree with that assessment.
Proposal
It would be so nice to be able to write it down like that, right?
Thoughts
SQLAlchemy will be the first instance to receive those options, while evaluating the ORM model. We will need to check where it breaks down the line, and whether we can do something to improve on behalf of the dialect implementation, or if there would be a need to improve SQLAlchemy itself to support such edge cases.
Bonus
The documentation about
__table_args__is also a bit thin, and should be improved.