addManyToOneRelation removes the FK from the schema but I have segments on it

Feature(s) impacted

Adding smart relationships while preserving the FK.

Observed behavior

Using addManyToOneRelation on a collection hides the foreign key from the .forestadmin-schema.json. This is problematic because we’re migrating from the old version on which we have multiple segments that depend on the foreign key.

Expected behavior

addManyToOneRelation should (optionally?) not remove the FK from the schema.


  • Agent technology: nodejs
  • Agent (forest package) name & version: 1.40.1 with sequelize 6.37.3 and sequelize-typescript 2.1.6
  • Database type: MSSQL
  • Recent changes made on your end if any: Migrating from old agent.

Can you try to use addField to force to re-add your foreign key?
Let me know if it works :slight_smile:

1 Like

Hi @Alban_Bertolini,

Sadly that did not do the trick.

I just succeeded by adding a second field in my Sequelize model:

  @Column({ allowNull: false, field: 'CompanyId' })
  declare CompId: string

  @Column({ allowNull: false })
  declare CompanyId: string

The database field being CompanyId, I sacrifice CompId to the addManyToOneRelation overlords and preserve CompanyId.

It’s not a pretty solution but it does the trick.

It could be nice to be able to preserve the foreign key in the model. Thankfully, your migration guides include section about comparing schemas, which is how I could notice that I was missing the FK.

Thank you for your time :slight_smile:


Hi @kll ,
Did you try import field ?
It should allow you to use any field of the relation as one of the source collection, and use it in your segment.


Plop @Enki!

Sadly that did not work. Adding the importField after addManyToOneRelation does nothing to the schema.

To check whether I was messing up I did try using importField with a random name than the foreign key field and it works fine, so the issue is really on the foreign key field.

Thank you for your feedback,

Indeed, the foreign key field is replaced with the relation, and cannot be remapped with another field. We can’t really fix this without reworking the whole system.
Your temporary workaround seems the right way to deals with your issue, at least until you migrate your segments to use the subfield “id” from the “company” field.

1 Like