The Wayback Machine - https://web.archive.org/web/20220409220142/https://github.com/sequelize/sequelize/issues/13429
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

Jump to bottom

Documentation mismatch? No type property on ForeignKeyOptions #13429

Open
xaragen opened this issue Aug 10, 2021 · 5 comments
Open

Documentation mismatch? No type property on ForeignKeyOptions #13429

xaragen opened this issue Aug 10, 2021 · 5 comments
Assignees
@Keimeno
Labels
good first issue type: docs

Comments

@xaragen
Copy link

@xaragen xaragen commented Aug 10, 2021 •
edited

Working on a project I ran into the documentation for customizing the Foreign Key.
The docs read:

// https://sequelize.org/master/manual/assocs.html
// For example, to use UUID as the foreign key data type instead of the default (INTEGER), you can simply do:

const { DataTypes } = require("Sequelize");

Foo.hasOne(Bar, {
  foreignKey: {
    // name: 'myFooId'
    type: DataTypes.UUID
  }
});
Bar.belongsTo(Foo);

Good enough, but when I went to work on it, it threw an error :

 Object literal may only specify known properties, and 'type' does not exist in type 'ForeignKeyOptions'

Looking at the files, it seems true. Is this correct behavior, missing type or incorrect documentation?

sequelize/types/lib/associations/base.d.ts

Line 37 in 56bb1d6

export interface ForeignKeyOptions extends ColumnOptions {

EDIT:

After working on this, looks like it does work but the option is not part of the ForeignKey Options as described in the docs.

Foo.belongsTo(Bar, {
    foreignKey: {
        name: 'myFooId',
    },
    as: 'bars',
    keyType: sequelize.DataTypes.STRING,
});
@Keimeno Keimeno added status: awaiting investigation type: bug labels Aug 10, 2021
@Keimeno Keimeno self-assigned this Aug 10, 2021
@Keimeno Keimeno removed the type: bug label Aug 10, 2021
@github-actions
Copy link
Contributor

@github-actions github-actions bot commented Oct 27, 2021

This issue has been automatically marked as stale because it has been open for 7 days without activity. It will be closed if no further activity occurs. If this is still an issue, just leave a comment or remove the "stale" label. 🙂
@github-actions github-actions bot added stale and removed stale labels Oct 27, 2021
@github-actions
Copy link
Contributor

@github-actions github-actions bot commented Nov 4, 2021

This issue has been automatically marked as stale because it has been open for 7 days without activity. It will be closed if no further activity occurs. If this is still an issue, just leave a comment or remove the "stale" label. 🙂
@github-actions github-actions bot added the stale label Nov 4, 2021
@Keimeno Keimeno added good first issue type: docs and removed stale status: awaiting investigation labels Nov 4, 2021
@bera5186
Copy link

@bera5186 bera5186 commented Feb 27, 2022

Hey @Keimeno !! I would like to work on this issue. Please guide me with next steps.
@ephys
Copy link
Member

@ephys ephys commented Feb 27, 2022 •
edited

This would be a good point to start an investigation: https://github.com/sequelize/sequelize/blob/main/src/associations/base.d.ts#L37
ForeignKeyOptions extends ColumnOptions, which doesn't include type
The only option bag that accepts type is ModelAttributeColumnOptions

The question is:

  • can type be moved from ModelAttributeColumnOptions to ColumnOptions (what other methods use ColumnOptions and do they accept type)
  • can foreign key extend ModelAttributeColumnOptions? Does it support all of these options
  • or do we need to create an intermediary type
@bera5186
Copy link

@bera5186 bera5186 commented Feb 27, 2022

Hey @ephys ,

ModelAttributeColumnOptions extends ColumnOptions , so all the properties of ColumnOptions should be accessible via extending ModelAttributeColumnOptions.

Looks like extending ModelAttributeColumnOptions in ForeignKeyOptions would work, but I think creating intermediary type is a better option.

Correct me if I am wrong. Waiting for your inputs on this !
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue type: docs
4 participants
@ephys @xaragen @bera5186 @Keimeno