Lack of Model inheritance effectively prevents some shared Vapor packages within an Organization about fluent-kit HOT 4 CLOSED

@tanner0101 Wouldn't the ORM need a discriminator column to tell which form of Nurse you are working with? Is there a complete example of this somewhere?

from fluent-kit.

I've transferred this to FluentKit since that's where Fluent's core APIs are located (including Model).

Vapor (and all of its packages) try to avoid inheritance like the plague. Mainly because it really doesn't mix well with protocols (as can be seen in your example). Given that protocols are generally more powerful than inheritance (they are composable), we just use protocols.

I'd be interested to see more concrete examples of what you are trying to do here with sub-classing and what difficulties you are having making it into a protocol.

from fluent-kit.

Having inheritance strategies like Single Table Inheritance and others would be handy to people coming from JPA based ORMs like Hibernate. There are cases when only the behavior of the entities differ and nothing else:

class Nurse {
    var employeeID: String
    var firstName: String
    var lastName: String
    //...
}

class RegisteredNurse : Nurse {}

class PracticalNurse : Nurse {}

/*
There are tasks that can be performed by all nurses, but 
some are restricted to Registered Nurses.  
*/

This is straightforward in JPA, but I don't see how to model it using Protocols (maybe Swift 7 will have abstract classes 😄 ).

from fluent-kit.

This is one way you could implement that design w/ protocols:

protocol Nurse {
    var employeeID: String { get set }
    var firstName: String { get set }
    var lastName: String { get set }
    //...
}

final class RegisteredNurse : Nurse {
    var employeeID: String
    var firstName: String
    var lastName: String
}

final class PracticalNurse : Nurse {
    var employeeID: String
    var firstName: String
    var lastName: String
}

from fluent-kit.