Fix encoders and decoders for java.util.UUID.

[mxl]

Fixes #594
Temporary workaround for #535 (only for JDBC)

Problem

• No UUID encoder and decoder in SqlContext.
• MySQL does not support UUID data type. Async and jdbc MySQL drivers does not support java.util.UUID conversion to some other type like String.
• It's not possible to override things in JdbcContext for specific SqlIdiom.
• quill-jdbc depends on driver libraries for all dialects which is not necessary when using one specific dialect.

Solution

• Implement missing UUID encoders and decoders.
• Split quill-jdbc to separate projects for each dialect.
• Make JdbcContext abstract and remove default uuidEncoder and uuidDecoder.
• Make separate JdbcContext for each dialect with mixed-in trait with custom uuidEncoder and uuidDecoder.
• Catch NPE in JDBC Option decoder as a temporary workaround for Decoders for custom types can potentially throw NPE #535.

Checklist

• Unit test all changes
• Update README.md if applicable
• Add [WIP] to the pull request title if it's work in progress
• Squash commits that aren't meaningful changes
• Run sbt scalariformFormat test:scalariformFormat to make sure that the source files are formatted

@getquill/maintainers

[mxl]

@getquill/maintainers Do you have any idea how to override encoder and decoder for specific Dialect <: SqlIdiom?

[mxl]

Postgres jdbc accepts UUID as object because postgres supports UUID type. But mysql does not support UUID and I want to encode it to String.

[mxl]

Should I make separate MysqlJdbcContext and PostgresJdbcContext like it's done for async?

[mxl]

@getquill/maintainers Done.

[fwbrasil]

UUIDEncoding would be more consistent with the codebase

[fwbrasil]

or UUIDObjectEncoding. Just saw the string version

[mxl]

You're right 👍

[fwbrasil]

@mxl sorry for the late feedback, I'm on vacation. The approach with specific context types looks good, but I'd like to avoid the sub-module "explosion". Considering that the specific contexts don't require more dependencies, wdyt about keeping all specific contexts under quill-jdbc?

[mxl]

@fwbrasil I have several pros for keeping separate sub-modules:

1. quill-jdbc-sqlite can be used by Android developers where resulting artifact (APK) size is important.
2. Having Oracle dialect #34 Hsql dialect #36 Support for MS SQL #451 implemented there will be much more dependencies in quill-jdbc module.
3. Also it's simpler to implement support for new dialects looking at separate module (e.g. quill-jdbc-mysql) and doing the copy of it with adjusting names (e.g. from MySQL to Oracle).
4. As @jilen suggested in Considering split finagle/async/cassandra sources to standalone project #646 we can one day come to solution to split this repository to separate repository for each module, leaving here only core module, which also will be easier to make already having separate jdbc modules.

[fwbrasil]

@mxl thanks for the clarification, I'm still not convinced, though.

quill-jdbc-sqlite can be used by Android developers where resulting artifact (APK) size is important.

I think most of the Android developers use something like proguard to remove unused classes/resources.

Having #34 #36 #451 implemented there will be much more dependencies in quill-jdbc module.

They should require only a test dependency, the published jar wouldn't have additional dependencies, right?

Also it's simpler to implement support for new dialects looking at separate module (e.g. quill-jdbc-mysql) and doing the copy of it with adjusting names (e.g. from MySQL to Oracle).

The same is true if we keep a single sub-module.

As @jilen suggested in #646 we can one day come to solution to split this repository to separate repository for each module, leaving here only core module, which also will be easier to make already having separate jdbc modules.

That's a good point, I agree that we should split the codebase into multiple sbt projects and allow different lifecycles for each module. For instance, we could have a new module that starts with version 0.1. Note that it doesn't mean that we'd need to split the git repo, we could keep a single repo since it'd be easier to make changes across repos and manage ci, release, etc.

I'd like to hear from the other maintainers, this is an important change. @getquill/maintainers

[mxl]

@fwbrasil

I think most of the Android developers use something like proguard to remove unused classes/resources.

Yes. I thought that default proguard setup does not shrink unused classes but it's the opposite.

They should require only a test dependency, the published jar wouldn't have additional dependencies, right?

Yes, but why is it done like that? Other Quill modules dependencies are not test-only (% Test). If it's done intentionally to make quill-jdbc not to pull extra dependencies then it looks a bit hackish. But if I'm wrong and it's a common practice then we should make the same thing with quill-async and quill-finagle, shouldn't we?

The same is true if we keep a single sub-module.

Agree. Copypasting single directory is a little easier but it's a weak argument. Actually when #379 will be implemented there will no need to duplicate tests so there will be only *JdbcContext class in quill-jdbc-* module.

That's a good point, I agree that we should split the codebase into multiple sbt projects and allow different lifecycles for each module. For instance, we could have a new module that starts with version 0.1. Note that it doesn't mean that we'd need to split the git repo, we could keep a single repo since it'd be easier to make changes across repos and manage ci, release, etc.

+1. I originally thought about splitting git repo but I agree that it will complicate things a lot.

Summarizing the above said, I just want us to develop a single approach to module organization for the case when we have some generic driver (quill-async, quill-jdbc, quill-finangle) that has implementations for multiple dialects.

[fwbrasil]

Yes, but why is it done like that? Other Quill modules dependencies are not test-only (% Test).

It's because quill-jdbc is based on jdbc interfaces that are provided by java by default.

If it's done intentionally to make quill-jdbc not to pull extra dependencies then it looks a bit hackish.

It's intentional but it's not hacky in any way. There's no need to depend on a specific vendor implementation, we only need the abstraction that jdbc provides.

But if I'm wrong and it's a common practice then we should make the same thing with quill-async and quill-finagle, shouldn't we?

They don't provide a unified interface for the different databases, that's the only reason to keep them separate. It'd be great if we could merge them.

[mxl]

@fwbrasil You're right. I have not thought about that. I've rolled back those changes and left only UUID encoding fix. If there will be any suggestions related to module organization I can make separate PR.

[fwbrasil]

@mxl awesome! :D