-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect mapping of team_user.team_id to user_id when using string primary keys #34
Comments
Hi, please provide additional information - what version of the package are you using, and how did you configure the model to work with string keys, setting $incrementing = false; or did you perform any additional actions? |
@Jurager I was using the latest version, the issue is not related to the primary key being string. I did a fresh installation of the package and it generated the same query. It won't throw a exception since the user_id and team_id is both int but nonetheless the query being generated seems incorrect. select "teams".*, "team_user"."team_id" as "pivot_team_id", "team_user"."user_id" as "pivot_user_id", "team_user"."role_id" as "pivot_role_id", "team_user"."created_at" as "pivot_created_at", "team_user"."updated_at" as "pivot_updated_at" from "teams" inner join "team_user" on "teams"."id" = "team_user"."user_id" where "team_user"."team_id" = 1) |
I am using version 2.4.5, the issue seems to be fix in branch 3.0. Is 3.0 the recommended branch I should be using @Jurager ? |
FYI this is what is causing the issue that was updated in branch 3.0 Line 35 in 187825c
|
When Teams configured to use a string as the primary key, the query appears to incorrectly map team_user.team_id to user_id instead of team_user.user_id. This results in a SQL error:
Steps to Reproduce
Expected Behavior
The generated query should correctly map:
teams.id to team_user.team_id
users.id to team_user.user_id
Actual Behavior
The generated query incorrectly maps team_user. team_id to user_id, leading to a SQL error when executing the query.
Additional Context
This behavior appears to be incorrect, as it does not align with the expected relationships defined in the schema. Please advise if this is a bug or if additional configuration is needed to resolve this issue when using string primary keys.
The text was updated successfully, but these errors were encountered: