Have you tried with the latest 3.0 release candidate?

Yes, I just tested it with version 3.0.0rc3 and it's the same

Note: Part of SQLAlchemy

# dialects\mysql\types.py
...
class CHAR(_StringType, sqltypes.CHAR):
    """MySQL CHAR type, for fixed-length character data."""

    __visit_name__ = "CHAR"

    def __init__(self, length=None, **kwargs):
        """Construct a CHAR.

        :param length: Maximum data length, in characters.

        :param binary: Optional, use the default binary collation for the
          national character set.  This does not affect the type of data
          stored, use a BINARY type for binary data.

        :param collation: Optional, request a particular collation.  Must be
          compatible with the national character set.

        """
        super(CHAR, self).__init__(length=length, **kwargs)
...

@agronholm this looks important. Maybe not for this milestone, but for the one after that

I can take a stab at this tomorrow if I have time.

I can take a stab at this tomorrow if I have time.

I can also have a look. Just wanted to make sure it doesn't get overlooked. I marked it for milestone 3.1.

@agronholm looking at this issue I can report that:

• No codegen errors
• No runtime errors
• No duplicate imports

The only remaining issue here, is the collation and charset data, while being reflected. is not part of the rendered column types. This is due to the fact the mysql.CHAR passes collation using kwargs, so signature identification taking place here cannot pickup on them. It does detect the kw args, but that's about all.

If I were to add some parent type signature parsing, it'd probably solve this issue .wdyt?

Finding the correct kwargs to add is a massive PITA. Does one of its parent classes take such keyword arguments?

To answer my own question, yes. But it takes plenty of other keyword arguments too. It seems just like I feared - that there is no way to automatically determine the correct keyword arguments to render.

In this case - the type hierarchy is mysql.CHAR -> sqltypes.CHAR -> sqltypes.String
I think it should not be too hard to implement a logic that, when encountering kwargs parse named arguments all the way to the simplest base type and then try and extract them from the passed kwargs dict. Do you see a scenario where this approach might break?

In this case - the type hierarchy is mysql.CHAR -> sqltypes.CHAR -> sqltypes.String I think it should not be too hard to implement a logic that, when encountering kwargs parse named arguments all the way to the simplest base type and then try and extract them from the passed kwargs dict. Do you see a scenario where this approach might break?

What passed kwargs dict? Where do we get that?

The signature and parameters extracted from a mysql.CHAR instance. Not sure I understand your question

I'm asking how we can reliably get the values passed to the class initializer. The classes are in no way obligated to retain attributes with the same names.

We're already getting the reflected type properly from SQLAlchemy. Meaning, the values it holds already rely on how implementation classes declare constructor field names and pass them up the type hierarchy. All we need to do is follow hierarchy constructor field trail in a best effort manner in order to make sure types are being rendered following the same principal. I believe it should work

We're already getting the reflected type properly from SQLAlchemy. Meaning, the values it holds already rely on how implementation classes declare constructor field names and pass them up the type hierarchy. All we need to do is follow hierarchy constructor field trail in a best effort manner in order to make sure types are being rendered following the same principal. I believe it should work

OK so in other words, follow the MRO, get initializer signatures, extract argument names and their default values, check for attributes with matching names whose values differ from the defaults?

Pretty much so