Skip to content
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

SqlBatch junction column name conflict #245

Open
bradzacher opened this issue Oct 2, 2017 · 4 comments
Open

SqlBatch junction column name conflict #245

bradzacher opened this issue Oct 2, 2017 · 4 comments

Comments

@bradzacher
Copy link
Contributor

When doing a junction sqlBatch, the column aliases assigned by JM can conflict, causing hydration to fail.

Eg.

const one = new GraphQLObjectType({
    // ...
    uniqueKey: 'id'
    // ...
})

const two = new GraphQLObjectType({
    // ...
    fields: {
        type: GraphQLList(one),
        join: {
            junction: {
                uniqueKey: 'id',
                sqlTable: 'junction_tbl',
                sqlBatch: {
                    parentKey: 'parentKey',
                    thisKey: 'thisKey',
                    sqlJoin: () => '', // ...
                },
            },
        },
    },
    // ...
})

doing a selection on this results in this sql:

SELECT
  `two`.`id` AS `id`,
  `two`.`id` AS `parentKey`
FROM two `two`;
-- batch --
SELECT
  `junction_t`.`id` AS `id`,
  `one`.`id` AS `id`,
  `junction_t`.`thisKey` AS `thisKey`
FROM junction_tbl `junction_t`
LEFT JOIN one `one` ON // ...
WHERE `junction_t`.`thisKey` IN (66,70,71,72,79,80)

as you can see in the batched SQL statement, one.id is aliased as id, so does junction_t.id. So when the data is hydrated, it ignores the junction table id column because it gets overwritten by the join table id column.

@br3nd4nn34l
Copy link
Contributor

br3nd4nn34l commented Nov 18, 2017

Commenting for visibility - experienced this exact same bug today.
I think this has something to do with the aliased field's template string having a new line in it. The code does set-ify the select statements to make them unique, but the extra newline technically makes the select statement different, so the set conversion doesn't eliminate it.

EDIT : I think I might have solved a similar but different issue.

@bradzacher
Copy link
Contributor Author

a workaround we've found for this is to define the unique key as a composite of itself: uniqueKey: ['id', 'id'],

This will add the unique key to the query as

CONCAT(id, '#', id) AS `id#id`

Thus working around the conflict

@tylerjbainbridge
Copy link

The uniqueKey: ['id', 'id'] workaround fixed it for me too- thanks.

@nicoabie
Copy link
Contributor

nicoabie commented May 5, 2024

Can you provide a https://github.com/join-monster/join-monster-sscce?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants