Allow defaultTableOptions to be configured

[DHager]

Change configuration metadata to unlock the use of defaultTableOptions, so that defaults can be passed to the schema-tool. In the case of MySQL, possible defaults include charset, collation, and engine.

The array-data is taken up here and then applied by individual platforms.

[DHager]

I'm assuming that documentation for this option will involve a separate, future PR against the separate symfony-docs repo.

So besides that, is there anything else I can do to help move this feature forward?

[stof]

@DHager Please add the documentation in the Resources/doc folder

[DHager]

@stof OK, I added some samples to the documentation folder. I can't enumerate all the possible options because they are situation-dependent on some DBAL platform internals.

Stylistically, default_table_options (in YAML) and default-table-option (in XML) would look a lot nicer, but the DBAL layer would still be looking for defaultTableOptions, and I'm not certain what the best mechanism would be for doing that conversion.

[stof]

@DHager we already have such a mechanism in the DoctrineExtension to rename keys to camelCase

[stof]

you are missing the ->fixXmlConfig() on the parent node for the XML to work properly

[DHager]

@stof : The pluralization is now fixed, but what I meant is that I'm not sure if there's a worthwhile way to let the user specify default-table-option (XML tag) and default_table_option (YAML key) while still putting something called defaultTableOptions into Doctrine-DBAL.

[DHager]

@stof: I think this one is done. Personally, it removes the need for a lot of <options> in every entity stating the desired character set and collation.

[DHager]

Are there any changes or checks I can do to help move this one along?

[stof]

the XML conventions are to use dash-separated words in keys, and the Yaml convention is to use snake_case. So yes, I would use such names in the config (we already have some logic in the DI extension converting to camelCase for Doctrine names; you just need to add it in the list)

[DHager]

OK, so you're saying that the meta-configuration layer does not handle all three varieties, only the dash and underscore variety, and any conversion to camelCase must be done with some ad-hoc code, correct? Perhaps in DoctrineExtension::dbalLoad()?

Are you sure all this convention-juggling is necessary? To some extent this is not structured configuration for the bundle to consume, but a complex payload we just want to pass-through so that DBAL can consume and interpret. (There are also several documented sibling-keys which break the pattern, such as sessionMode, sslmode, and MultipleActiveResultSets.)

[DHager]

OK, I've added some code that--after loading configurations--renames/replaces them as camelCase. The rename has to occur in order to satisfy DBAL code in AbstractSchemaManager which looks specifically for that string.

[DHager]

@stof : It ought to match the XML/YAML conventions now. Anything else?

[stof]

we already have code doing this. See getConnectionOptions. Just add this option there

[DHager]

@stof : Fixed the conversion step to use the existing mechanism. Thanks, didn't see it there.

[DHager]

@stof Is there anything else?

[DHager]

Ping

[DHager]

@stof: Ping

[DHager]

@stof: Ping

[DHager]

@stof : Weekly checkin.

[DHager]

@stof Anything else I can do to make this merge-ready? Personally speaking, it should let me avoid putting

    <options>
        <option name="charset">utf8mb4</option>
        <option name="collation">utf8mb4_unicode_ci</option>
    </options> 

across hundreds of <Entity> definitions.

[teohhanhui]

Since @stof is not giving any response, perhaps it's time to ask the other maintainers...

@fabpot @beberlei