How do I combine the safety of type requirements with the safety of enums?

351 views Asked by At

So I'm working on an sql database abstraction layer in swift and I want to write it as safe as possible. By that I mean I would prefer to make it impossible for anybody to do anything illegal in the database using my library.

One thing I'm not fully able to solve yet is how to make the conversion from Swift types to SQL data types 100% safe. So I'll explain my current implementation and its flaws:

So in SQL, many data types have parameters. For example, when you want to define a column as a VARCHAR, you need to give it a parameter that represents the max length of the VARCHAR, like VARCHAR(255). You could say that VARCHAR is one of SQL's primitive data-types and VARCHAR(255) is a more specified data-type. To represent that in a type-safe way in swift I created two protocols:

public protocol PrimitiveDataType {
    associatedtype Options = Void
}

public protocol SpecifiedDataType {
    associatedtype Primitive: PrimitiveDataType

    static var options: Primitive.Options { get }
    static func from(primitive: Primitive) -> Self
    var primitive: Primitive { get }
}

So here's an example of a PrimitiveDataType:

extension String: PrimitiveDataType {
    public enum DatabaseStringType {
        case char(length: Int), varchar(limit: Int), text
    }

    public typealias Options = DatabaseStringType
}

And here's an example of a SpecifiedDataType:

struct Name {
    let value: String

    init?(_ value: String) {
        guard case 0...50 = value.characters.count else {
            return nil
        }

        self.value = value
    }
}

extension Name: SpecifiedDataType {
    static let options = String.DatabaseStringType.varchar(limit: 50)

    static func from(primitive: String) -> Name {
        return Name(primitive)!
    }

    var primitive: String {
        return value
    }
}

Now I can use the information elsewhere in the library to know what kind of database-column is expected whenever a Name type is requested. This gives my library the power to make sure the database columns are always of the correct type.

I haven't written all that code yet, but it might look something like this:

func createColumn<SDT: SpecifiedDataType>(ofType type: SDT) -> String {
    switch SDT.options {
    case let options as String.DatabaseStringType:
        switch options {
        case .text:
            return "TEXT"
        case .char(let length):
            return "CHAR(\(length))"
        case .varchar(let limit):
            return "VARCHAR(\(limit))"
        }
    case let length as UInt32.Options:
        // return something like UNSIGNED INTEGER(\(length)) or whatever

    // case etcetera
    }
}

There is just one small problem with this. The set of valid primitive data-types is limited, but the set of possible implementations of the PrimitiveDataType protocol is unlimited, because I can't stop anybody from creating their own implementation of this protocol.

So for this reason it would be better to use some kind of enum instead of a number of implementations of a protocol. Because nobody can extend an enum that I create, so I can keep the options limited to whatever I define as valid types. However, an enum would create another problem that doesn't exist in my current implementation.

You see in my current implementation, whenever someone implements SpecifiedDataType with their options defined like so:

static let options = String.DatabaseStringType.varchar(limit: 50)

I can trust that the compiler will force them to make their type compatible with string by implementing the from(primitive: String) method and the primitive: String (computed) variable. AFAIK, if I switch the protocol for an enum I lose this compiler-enforced type-safety.

So in summary, I want to have all of the following:

  • A way for a developer to declare what sql data-type they want their type to correspond with.
  • A way to then force that developer to actually make their type compatible with that sql data-type.
  • To guarantee that the developer using my library can't somehow extend the list of sql-data types, but can only use the ones that I have defined for him / her.

So far I only know how to do either the first two, but not the last one, or the last one, but not the first two. How do I get all three?

0

There are 0 answers