Changes to support looking up a Dialect by name.

[wynan]

Looking to be able to set a dialect using spring properties and looking for a way to select a dialect by name. See the Spring changes for an example of how this would be used.

As usual let me know if this doesn't make sense, you would prefer a different approach or if there is anything else you would like me to address.

[badgerwithagun]

Thanks @wynan!

It's not completely obvious when you read the code, but there is a slow effort to decouple Dialect (which was originally an enum!) from its implementations. The end goal is that the individual DB implementations could be moved to separate modules.

The static references to the individual implementations in this interface purely exist for backwards compatibility, and will likely be removed at some point. Theoretically, also, someone out there may have some custom Dialect implementation for a different database which they've not shared with the project and won't be listed here.

All this means I instinctively dislike this approach. What I would prefer to see is:

• The implementations extracted into their own classes (e.g. OracleDialect, H2Dialect...)
• Spring configuration using a class FQN, e.g. com.gruelbox.transactionoutbox.OracleDialect.

[badgerwithagun]

Change requested

[wynan]

Let me know if this refactoring is way off base. I’m not a fan of how the migrations are handled at this point but this allows them to operate in a similar manner and this allows me to achieve my objective and I think moves things in the right direction. Seems like we would have to pull more SQL statements out of the service methods and into the BaseDialect so they could be overwritten as needed.