Refactored the Dialect to use an interface to generate the DB specific SQL.

[wynan]

Plan to add SQL Server support and this seemed like the time to refactor the Dialect into a proper interface. No functional changes.

[badgerwithagun]

This looks sensible. However, it's quite a compatibility break. This could be avoided to a degree (if we ignore binary compatibility) by:

1. Just change Dialect into an interface
2. Include the original implementations as inner classes of Dialect
3. Add public static final properties exposing instances of those inner classes to replace the enum properties

e.g.

public interface Dialect {

  static final H2 = new H2Impl();

  static final class H2Impl implements Dialect {
  }

}

I think this would clean up a lot of the "splash damage" around the rest of the codebase.

[wynan]

Will do. I was trying to keep Dialect an Enum and create a new concept to encapsulate the SQL differences but I'll go ahead and change Dialect to an interface.

[wynan]

@badgerwithagun Let me know if you see anything else you want updated or want further changes. I feel like the migration code could be refactored as well but wanted to keep this change tight and small.

[wynan]

@badgerwithagun Let me know if you see anything else you want updated or want further changes. I feel like the migration code could be refactored as well but wanted to keep this change tight and small.