Extensible Schema Creation

[NathanFlurry]

Name of Feature

• Author(s): Nathan Flurry
• Status: Awaiting review

Introduction

Table and rows have many essential database-specific constraints and row types. Right now, to access these features, one has to do manually alter tables after creation like try mysql.driver.raw("ALTER TABLE \(entity) CHANGE text text VARCHAR(191) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci") to get a custom character set.

Proposed solution

It would be much better if there was a way that each database package could extend the schema creation library to allow for custom constraints and row types. For example, the new extended format for schema creation would look like this:

try database.create(entity) { users in
    users.charset("utf8_mb4")
    users.row("id").id()
    users.row("name").string(191).charset("utf8_mb4").unique() // Assumes `varchar` type in Postgres; could also say `users.row("name").varchar(191)`
    users.row("ip").cidr()
}

Notice the use of charset() and cidr(). These would be extensions from the PostgreSQL driver on Fluent allowing access to database-specific row types and constrains.

By calling row(name), this creates a Row object which can be extended to add custom properties like cidr() (which changes the row type) and charset() (which would add a charset constraint to the row).

Notice the Schema itself can also have constraints added to it just like rows, e.g. users.charset("utf8_mb4").

This would make issues like #74 quick fixes in the driver itself instead of alterations to Fluent itself.

Impact

This would require a lot of the Fluent library itself to be refactored to work with extensions. This would also break any existing schema code.

Alternatives considered

The alternative is to continue statically adding more and more data types that may or may not be supported by databases. Any database-specific features would have to be accessed using raw SQL ALTER queries.

Decision (For Moderator Use)

On [Date], the community decided to (TBD) this proposal. When the community makes a decision regarding this proposal, their rationale for the decision will be written here.

[BrettRToomey]

The new schema.raw() makes this a lot easier to deal with. Closing this for now.