Structured Queries macro @Table not compatible with default settings of MutablePersistableRecord table naming

[whoyawn]

Description

I followed the migration docs and it had no mention of removal of MutablePersistableRecord and FetchableRecord, so when I called inserted to seed my database, I got a crash of
error: SQLite error 1: no such table: {SINGULAR_SPELLED_NAME_OF_TABLE}

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• I have determined whether this bug is also reproducible in a vanilla GRDB project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

The workaround is either switching the table name via @Table("syncUp") or declaring static var databaseTableName = "syncUps"

I would like to be able to use the default @Table macro without any other changes to the naming of the table. The cleanup of FetchableRecord and MutablePersistableRecord and the use of the new seeding function is also not documented, in the migration guide, I would like to see all the new APIs that should be used with 0.2.2 moving from 0.1.0

Actual behavior

Here is it demonstrated in the example project:

Add this back under the @Table struct SyncUp { ... }

extension SyncUp: Codable, MutablePersistableRecord {
    
    mutating func didInsert(_ inserted: InsertionSuccess) {
        id = Int(inserted.rowID)
     }
}

extension Theme: Codable {}

and where seedSampleData() is defined, add this line

      try! SyncUp(id: 4, seconds: 60, theme: .appOrange, title: "Design").inserted(self)

Then run the project, and we'll see:

SyncUps/Schema.swift:171: Fatal error: 'try!' expression unexpectedly raised an error: SQLite error 1: no such table: syncUp

Reproducing project

mutablePersistableRecordBug.patch

apply this patch to the example project

SharingGRDB version information

0.2.2

Sharing version information

2.4.0

GRDB version information

7.4.1

Destination operating system

iOS 18

Xcode version information

No response

Swift Compiler version information

[stephencelis]

Hi @whoyawn,

This behavior comes from StructuredQueries, and is working as intended. StructuredQueries is designed to work with any database or database library, not just GRDB. We have decided to adopt the convention of pluralization (used by Ruby on Rails, for example) rather than GRDB's convention.

If you are migrating existing types that use the GRDB convention, you must pass an explicit table name to the @Table macro, as you mention as a workaround.

Because this is not a bug in the library I'm going to convert it to a discussion.

[stephencelis]

One other note. StructuredQueries has its own type/schema-safe helpers for INSERT, UPDATE, and DELETE statements, so you are able to remove the MutablePersistableRecord conformances and rely on the @Table macro for this functionality, instead.

[whoyawn]

It still feels unintentional that in the StructuredQueries that ships with SharingGRDB, using @Table to rename tables will cause a runtime error and not a compiler error if the names are mismatched. I'm not familiar with creating macros, but I would expect the data source for the table string to be the same source of truth as calling static var databaseTableName.

For example, this causes a crash:

// Schema.swift

@Table("syncUps")
struct SyncUp: Hashable, Identifiable {
//    static let databaseTableName = "syncUps"
    var id: Int
  var seconds: Int = 60 * 5
  var theme: Theme = .bubblegum
  var title = ""
}

  migrator.registerMigration("Create sync-ups table") { db in
    try #sql(
      """
      CREATE TABLE "syncUps" (
        "id" INTEGER PRIMARY KEY AUTOINCREMENT,
        "seconds" INTEGER NOT NULL DEFAULT 300,
        "theme" TEXT NOT NULL DEFAULT \(raw: Theme.bubblegum.rawValue),
        "title" TEXT NOT NULL
      )
      """
    )
    .execute(db)
  }

      try! SyncUp(id: 4, seconds: 60, theme: .appOrange, title: "Design").inserted(self)

whereas if you uncomment databaseTableName, it will run.

[mbrandonw]

Hi @whoyawn, it wouldn't be correct for us to bake in logic for @Table in order to accommodate GRDB. As Stephen mentioned, @Table has aspirations to support many more database systems beyond just SQLite.

Also, the inserted method you are using comes from GRDB, not our library, and so it shouldn't be too surprising that it is not compatible with how the code is written now. If you wanted to use our tool, it would be more like this:

try SyncUp
  .insert(SyncUp.Draft(…))
  .execute(db)

That constructs an "INSERT INTO" SQL statement using StructuredQueries, and then executes it.

So, in our opinion you are straddled between two worlds right now, and that is why it doesn't work. You are using our tools for the static table schema, @Table, and using GRDB tools to generate the queries. So, if you want to continue using GRDB query builder tools, then you should leave databaseTableName. And if you want to use @Table you should use our query builder tools.