Macro-based CloudKit configuration via @SyncedTable/@SyncedField

[lukaskubanek]

In recent discussions in the SQLiteData repo, a potential pattern has emerged for designing CloudKit-related configuration APIs using macros applied directly to table types and their fields.

The main benefit of this approach is that CloudKit configuration can live close to the data it describes, rather than being defined indirectly in the initializer of SyncEngine. This also scales better as additional configuration options are added. The main downside is that this likely can’t be folded into the existing @Table macro, and would instead require introducing a new sync-aware type-level macro.

See these discussions for more context:

• API ideation for customizable conflict resolution
• Discussion on configuring encryption for fields & follow-up discussion in PR #336

I’ve decided to open this high-level discussion specifically to explore the macro-based pattern, and to provide a shared reference point for discussion and experimentation.

Here is a list of options the macro pair could support that come to mind:

@SyncedTable

• Record name
• Shareability (currently via tables and privateTables parameters in SyncEngine.init)
• Master flag for field encryption (applied to all fields)

@SyncedField

• Field name
• Encryption flag (override of table-level flag)
• Merge policy (for customizable conflict resolution)
• Representation of data fields (blob vs. CKAsset)

Example

A definition of a table with minimal configuration options:

@SyncedTable
struct Post: Identifiable {

  let id: UUID

  var title: String

  @SyncedField(encrypted: true)
  @Column("content")
  var body: String

  @SyncedField(mergePolicy: .counter)
  var votes = 0

}

The same model with all defaults made explicit and the field-level macros expanded:

@SyncedTable(
  recordName: "Post",
  isPrivate: false,
  encryptFields: false
)
struct Post: Identifiable {

  @SyncedField(
    name: "id",
    encrypted: false,
    mergePolicy: .latest
  )
  @Column(…)
  let id: UUID

  @SyncedField(
    name: "title",
    encrypted: false,
    mergePolicy: .latest
  )
  @Column(…)
  var title: String

  @SyncedField(
    name: "content",
    encrypted: true,
    mergePolicy: .latest
  )
  @Column("content", …)
  var body: String

  @SyncedField(
    name: "votes",
    encrypted: false,
    mergePolicy: .counter
  )
  @Column(…)
  var votes = 0

}

This shows how an ideal syntax could look like, but I’m not sure how exactly the @SyncedTable macro would get the expansion logic from the stock @Table macro, as I’m not that familiar with macro development.

I simply wanted to get a sense of whether this is a direction for the library worth exploring, given the new configuration options that are being discussed.

[mbrandonw]

This shows how an ideal syntax could look like, but I’m not sure how exactly the @SyncedTable macro would get the expansion logic from the stock @Table macro, as I’m not that familiar with macro development.

Hi @lukaskubanek, thanks for opening this discussion, and this approach is indeed how Stephen and I think things should go. The key to it is solving what you describe above. To do this we will need to "library-ify" the macros in StructuredQueries. That is, extract out the guts of the macro expansion code into its own library so that its core components can be called from SQ's macros as well as SQLiteData's macros. That will allow @SyncedTable to expand everything from @Table and add more code depending on what it sees inside the struct.

That would be the first step towards this, and we plan on looking into it at some point, but also if you are inclined to explore do let us know what you find!

[lukaskubanek]

@mbrandonw Great to hear that this aligns with the desired direction of the library!

While the idea of library-ifying the current macro expansion logic sounds viable, I don’t feel I have enough expertise to contribute there. My plan is to continue looking into customizable conflict resolution per #272, particularly the macro-based approach outlined in this comment.