Skip to content

Conversation

@KayLeung
Copy link
Contributor

I'm facing the same issue described at
https://github.com/pointfreeco/sharing-grdb/discussions/107

When you join two tables, it becomes a tuple (TableA, SomeOtherTable)
The where method expects the Joins to be a parameter pack (repeat each J)

When you join one table, it return single Table type (not a tuple or empty)?

(Sorry. Not so familiar with Swift. Maybe some better way to handle it)

Copy link
Member

@stephencelis stephencelis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to be another unfortunate Swift parameter pack bug and it's a bummer we need even more overloads to work around it 😕

I think an overload is required per builder, though. Chaining into a having, group(by:), etc., all have the same problem.

It would also be nice to get some compile-time test coverage on these overloads.

Are you down to tackle these issues in this PR? If not we can help finish things up. Took care of it!

Copy link
Member

@stephencelis stephencelis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to check some of this stuff so I ended up pushing those changes! Brandon and I will discuss and hopefully merge soon. Thanks again for bringing this to our attention 😄

}

@Test func singleJoinChaining() {
let base = Reminder.group(by: \.id).join(ReminderTag.all) { $0.id.eq($1.reminderID) }
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it doesn't test on the actual bug.

it is always working, without patch also working:
Reminder.group(by: \.id).join(ReminderTag.all) { $0.id.eq($1.reminderID) }

tricky is only not working at this case:
Reminder.group(by: \.id).withReminderTagJoin

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this line compiles fine, the lines below it triggered what I think were equivalent compiler errors without the overloads defined in this PR. The issue doesn't seem to be related to the static dynamic member lookup.

@KayLeung
Copy link
Contributor Author

also,
.and & .or should patch too or another new issue?

my quick test:

_ = base.and(.where { r, _ in r.isCompleted })
     |   `- error: contextual closure type '(Reminder.TableColumns) -> TableColumn<Reminder.TableColumns.QueryValue, Bool>' (aka '(Reminder.TableColumns) -> TableColumn<Reminder, Bool>') expects 1 argument, but 2 were used in closure body

@stephencelis
Copy link
Member

@KayLeung and and or take Where, which is generic over a single table, so it can only predicate based off the base table. We could consider taking full SelectStatement here instead, but yeah let's save that for another PR/issue.

@stephencelis stephencelis merged commit 388c255 into pointfreeco:main Jul 28, 2025
3 checks passed
coenttb pushed a commit to coenttb/swift-structured-queries-postgres that referenced this pull request Oct 14, 2025
* Handle single Join & Where on query helpers

* wip

---------

Co-authored-by: Stephen Celis <[email protected]>
coenttb pushed a commit to coenttb/swift-structured-queries-postgres that referenced this pull request Oct 15, 2025
* Handle single Join & Where on query helpers

* wip

---------

Co-authored-by: Stephen Celis <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants