Add constraint naming convention configuration option

[leonarduschen]

Closes #193

[agronholm]

FYI, I'm planning one last big refactoring before the final release (one which should resolve the issue of code duplication) and it will probably clash with this PR.

[leonarduschen]

Right, I'm actually working on 2 additional issues, details outlined in #193 (comment)

Those issues are only relevant when using these 2 types of tokens:

• %(referred_column_0_name)s, %(referred_column_0_N_name)s, %(referred_column_0N_name)s, etc
• %(constraint_name)s

I was thinking of doing everything in one go in this PR, but if you're going to do a big refactoring then perhaps I should just fix those in subsequent PRs? For now we can add a note in the docs that those tokens cannot be used.

Let me know what you think.

[coveralls]

Coverage increased (+0.02%) to 99.744% when pulling f501697 on leonarduschen:add-constraint-naming into 5029eb1 on agronholm:master.

[agronholm]

I've opened #200 to address the design choice of config file support which we probably need for this.

[leonarduschen]

I added the option to add the naming convention via command line on top of config file (which hasn't been added yet)

I was thinking, for each config option, we can go like this:

• Check if it is available as command line arg
• If not, check if it is available in config file
• If not, fall back to default value

[agronholm]

How would users know what to enter here, based on this?

[leonarduschen]

Well we assume users interested in using this option are already familiar with SQLAlchemy's constraint naming convention feature from https://docs.sqlalchemy.org/en/14/core/constraints.html#configuring-constraint-naming-conventions or https://alembic.sqlalchemy.org/en/latest/naming.html. In this case, the help string above would enough in my opinion.

We can also add more details in README:

• Link to SQLAlchemy/Alembic docs above
• Maybe also basic info about constraint naming convention and its usage in SQLAlchemy, basically summarizing the docs above
• Things supported in SQLAlchemy but not in sqlacodegen:
  • Using custom function as naming convention token
  • Using the constraint object name as key instead of mnemonic (e.g., PrimaryKeyConstraint cannot be used as key, must use pk)

[leonarduschen]

I've addressed the 2 issues I mentioned earlier #193 (comment) - ready for review now