Strategy to handle nested records

[tgrapperon]

Hello!
Let say that I have a model with two types A and B such as:

struct A: PersistableRecord, FetchableRecord, TableRecord {
  let id: String
  var b: B
}
struct B: PersistableRecord, FetchableRecord, TableRecord {
  let id: String
  let value: Int
}

So A and B are both record-like types. Sometimes I handle B's, sometimes As. I would like these types to stay like this (that is having a fully fledged B value in A, not a B.ID). Is this possible to work directly with these values without resorting to an intermediary AProxy type that would reference B through its identifier?
Thanks!

[groue]

Hello @tgrapperon,

I don't doubt that the A type is the one you want your app to use. It's the "canonical" model. My advice is to not make it use unfit protocols.

A can implement FetchableRecord (please refer to its documentation, as well as the Associations guide).

But A is not a "table record", because TableRecord is all about single tables. For example, when TableRecord generates SQL for A.fetchAll(db), it does not embed the Bs.

And A is not a "persistable record" either. If you think about it, persisting a composite object such as A supports multiple strategies. For example, what deleting an A should do? Maybe your app wants to delete rows in both the A and B tables. Maybe some other app would prefer deleting a row in A only, leaving an orphan B. Both options are valid, depending on the context. Similar questions, and options, are raised by other persistence methods (maybe your app has one need, obvious in the context of your app, but other apps may differ). Since there are so many possible options, GRDB does not address the topic of composite records in PersistableRecord. It's the application's job (performed outside of PersistableRecord).

Using unfit protocols will create mismatches and oddities that are the signs that the application is fighting the framework.

All in all, the AProxy type, the one that is responsible for the A database table (exclusively), may well be helpful as a supporting type for A (a type that is not really related to the database).

For further information, and details about the setup expected by GRDB, see the related sections in the Recommended Practices for Designing Record Types guide:

• Persistable Record Types are Responsible for Their Tables
• How to Model Graphs of Objects

I'm not saying this is ideal, and there is certainly room for improvements. Previous issues shed some light on the problems to solve: #1322, #1354.

[tgrapperon]

Thanks so much for your quick and very helpful answer. You're right, I can probably use a composite approach for A. This is what I already tried to do (and I immediately saw the degrees for freedom we have regarding sub-records management), but I was unsure if I was missing something already built-in.
Encore merci!