Callbacks as Rails

[abournier]

Hello,

I just start learning GRDB. It looks like amazing.
However, is there a feature like Callbacks in Rails ? (beforeSave, afterSave, beforeCreate...)

I have found "didInsert" after an insert is performed. But is there an equivalent to "beforeSave" ? It could be useful, for example, to share code between multiple models.

As an example, I used this to generate at the right place an Id as UUID string:

extension Wine: MutablePersistableRecord {

		// MutablePersistableRecord protocol
		mutating func insert(_ db: Database) throws {
				generateUuidStringAsId()
				do {
						try performInsert(db)
				}
				catch {
						print("Unable to write the record !")
				}
		}
		
}

But I have 10 models using an UUID string as Id. If I could have something like:

beforeCreate() {
  generateUuidStringAsId()
} 

without having to implement insert() for all my models, it could be very helpful.

[groue]

Hello @abournier,

You shouldn't catch the insertion error. I don't understand why so many developers have such a urge to hide errors by catching and printing them, so that nobody can never look at it and handle it once the error happens in production. It's important to be able to look at errors straight in the eyes, because this is the real way to make applications robust.

Your sample code should instead read as below, with all the useless error handling removed:

extension Wine {
    func insert(_ db: Database) throws {
        generateUuidStringAsId()
        try performInsert(db)
    }
}

But now I don't find that it's that much heavier than:

extension Wine {
    func beforeCreate() {
        generateUuidStringAsId()
    }
}

And I don't understand how callbacks would make your code significantly simpler. I understand you may be used to ActiveRecord callbacks, but I'm not sure it's significantly more difficult to get used to the GRDB technique.

[groue]

In Rails, beforeSave() is called by AR automatically when saving the record. In your example, I need to call myself beforeCreate() somewhere, so I suppose in the insert() method too...

Yes @abournier. I guess it would look like, according to the ActiveRecord callback ordering:

extension Wine {
    func beforeSave() { ... }
    func beforeCreate() { ... }
    func beforeUpdate() { ... }

    func afterCreate() { ... }
    func afterSave() { ... }
    func afterUpdate() { ... }

    mutating func insert(_ db: Database) throws {
        beforeSave()
        beforeCreate()
        try performInsert(db)
        afterCreate()
        afterSave()
    }

    func update(...) throws {
        beforeSave()
        beforeUpdate()
        try performUpdate(...)
        afterUpdate()
        afterSave()
    }
}

You will have to override save as well, because by default this method attempts at updating before inserting. This may trigger "before update" callbacks and then "before create" callbacks. This is left as an exercice for the reader.

[groue]

I read your counter arguments, but I'm not as expert as you in Rails internal mechanisms.

When I am asked to implement such a feature, I have to wonder, as anybody, "but how would I do that??". Eventually I have to learn things. You can do it as well, @abournier.

All my arguments and counter-arguments above are thought experiments where the only rule is to take your request seriously. From that I try to derive consequences, so that I can evaluate the request. You can do it as well.

Callbacks were just a suggestion, after seeing the way you build GRDB associations as Rails (has_many, belongs_to...).

I 100% understand, and I'm happy this inspiration has helped you entering GRDB :-)

[abournier]

Yes @abournier. I guess it would look like, according to the ActiveRecord callback ordering:

extension Wine {
    func beforeSave() { ... }
    func beforeCreate() { ... }
    func beforeUpdate() { ... }

    func afterCreate() { ... }
    func afterSave() { ... }
    func afterUpdate() { ... }

    mutating func insert(_ db: Database) throws {
        beforeSave()
        beforeCreate()
        try performInsert(db)
        afterCreate()
        afterSave()
    }

    func update(...) throws {
        beforeSave()
        beforeUpdate()
        try performUpdate(...)
        afterUpdate()
        afterSave()
    }
}

You will have to override save as well, because by default this method attempts at updating before inserting. This may trigger "before update" callbacks and then "before create" callbacks. This is left as an exercice for the reader.

Thanks for the code. The callbacks positions seem logical.

I read your counter arguments, but I'm not as expert as you in Rails internal mechanisms.

When I am asked to implement such a feature, I have to wonder, as anybody, "but how would I do that??". Eventually I have to learn things. You can do it as well, @abournier.

All my arguments and counter-arguments above are thought experiments where the only rule is to take your request seriously. From that I try to derive consequences, so that I can evaluate the request. You can do it as well.

Before asking, I had a look at the entire MutablePersistenceRecord protocol to see how things were made with insert(), didInsert() and the default implementation methods. My first idea was to extend this protocol for my needs.

Well, at the time, my only need was to have a way to not repeat the uuid creation for each model. That's why more generally why the callback idea come to me.
I also created another protocol UuidStringAsId that creates the uuid as string, with a default implementation, that my models can conform to.

Thanks for the proposals,
Have a good week-end,

[groue]

Well, at the time, my only need was to have a way to not repeat the uuid creation for each model. That's why more generally why the callback idea come to me. I also created another protocol UuidStringAsId that creates the uuid as string, with a default implementation, that my models can conform to.

You wanted several records to perform a custom insertion (generate a UUID) simply by inheriting a protocol, right? Maybe you had something like the sample code below in mind?

protocol UuidStringAsId: MutatingPersistableRecord {
    var uuid: UUID? { get set }
}

// Conforming to UuidStringAsId grants automatic UUID generation on insert
extension UuidStringAsId {
    // Default implementation for the callback.
    mutating func beforeCreate() {
        if uuid == nil { uuid = UUID() }
    }
}

extension Wine: UuidStringAsId { }
extension Grape: UuidStringAsId { }
extension etc: UuidStringAsId { }

My concern with such inspiration from ActiveSupport Concerns (pun intended) is that with such a setup, you quickly hit a wall. Once a concern has been defined, it is natural to want more. For example:

protocol CreationDateTracking {
    var creationDate: Date? { get set }
}

extension CreationDateTracking {
    mutating func beforeCreate() {
        creationDate = Date()
    }
}

extension Wine: UuidStringAsId, CreationDateTracking { }
extension Grape: UuidStringAsId, CreationDateTracking { }
extension etc: UuidStringAsId, CreationDateTracking { }

I guess you would expect both callbacks to be run, right? Unfortunately, the Swift compiler disagrees.

My role here is to make sure we do not over-promise. Opening a door (hey, look at Rails-like callbacks!) and closing it too soon due to a bad match between a foreign feature and the language is a clear disservice to the library and its users.

Your feature request is relevant. I just don't know how to implement it today, in a way that supports all the wonderful variety of life (the wild needs of other users).

[abournier]

Completely true. So I forgot the callbacks, and just used this approach at the time:

protocol UuidStringAsId {
		
		var id: String? { set get }
		
		mutating func generateUuidStringAsId()
}

extension UuidStringAsId {

		mutating func generateUuidStringAsId() {
				if id == nil {
						id = UUID().uuidString.lowercased()
				}
		}		
}

struct Wine: Codable, Identifiable, UuidStringAsId  {
		
		// Database table name
		static let databaseTableName = "usr_wines"
		
		// Properties
		var id: String?		
		var name: String
		var countryId: Int64?
}

// Model persistence
extension Wine: MutablePersistableRecord {

		// MutablePersistableRecord protocol
		mutating func insert(_ db: Database) throws {
				generateUuidStringAsId()
				try performInsert(db)
		}		
}

If I need new protocols, I can create them and add them in insert() method.

[groue]

@abournier, GRDB 6 has callbacks :-)

[abournier]

Hello @groue,

It looks amazing. I will test them as soon as possible.
Thanks for all your energy given to this project.

[groue]

You're welcome :-) I pretty much copied the Rails callbacks: willInsert matches before_create, etc.