Support user defined data types when describing table schema.

[sviezypan]

This PR introduces new way to describe tables with the defineTable[A] method.

Old way to define table schema was by using DSL and ++ operator.

val customers =
      (uuid("id") ++ localDate(“date_of_birth”) ++ string("first_name") ++ string("last_name") ++ boolean("verified_customer") ++ zonedDateTime("created")).table("customers")

    val (customerId, dob, fName, lName, verified, createdString, createdTimestamp) = customers.columns

While composable, it was a bit boilerplate-y and another DSL to learn. I think that for Scala devs its more natural to write a case class, which could be then reused when doing select or insert with the same table.

  case class Customer(id: UUID, dob: LocalDate, firstName: String, lastName: String, verified: Boolean, 
createdTimestampString: String, createdTimestamp: ZonedDateTime)

We can get table description just by calling defineTable[Customer] method. The case class data type also needs an implicit schema (which is required for inserts anyway)

    implicit val custommerSchema = DeriveSchema.gen[Customer]

    val customers = defineTable[Customer]

    val (customerId, dob, fName, lName, verified, createdString, createdTimestamp) = customers.columns

There are 2 overrides
defineTableSmart[Customer] and defineTable[Customer]("customers"), where the first one smartly tries to make plural out of case class name, while taking into account also irregular english plural words.
OrderOrigin -> order_origins
PersonAddress -> person_addresses
Foot -> feet
defineTable[Customer]("customers") takes table name explicitly.
Field names are also converted from camelCase to snake_case
firstName -> first_name

There is also a macro which verifies that data type can be used to describe table ( sql does not know sum types). For example:

    sealed trait PaymentMethod
    case object Card extends PaymentMethod
    case object Cash extends PaymentMethod

    case class Bill(amount: Int, paymentMethod: PaymentMethod)
    
    val billTable = defineTable[Bill]

defineTable[Bill] will emit an compilation error
Unsupported types by SQL OrderDetails.PaymentMethod

@jdegoes @jczuchnowski let me know what you think. Docs are updated as well.

[jczuchnowski]

doesn't seem to be needed

[sviezypan]

Unfortunately we don't support scala.math.BigDecimal until I add TypeId to Schema.Transform. scala.math.BigDecimal is encoded as Schema.transform of java.math.BigDecimal and without TypeId on Transform I am not able to derive TypeTag for scala.math.BigDecimal.

[jczuchnowski]

We should still have tests that are using the "old way".

[sviezypan]

We are not supporting ++ for definition of "source" tables. Let's discuss if there's a use case for having both.

[jczuchnowski]

👍

[jczuchnowski]

So this is a problem only on m1 machine?

[sviezypan]

No, the test is failing everywhere but I am not able to reproduce on m1 because of oracle image not running at all.

[jczuchnowski]

Later in section Subqueries & Correlated subqueries of this document, there are still examples of this kind of definitions but without explanation.
I think we should have both ways well documented. The ++ operator is still useful for defining simple ad-hoc queries for which we don't need to define a model.

[sviezypan]

As I replaced ++ with data type definition, I now changed it in all places in docs.