Migration to @forestadmin/agent - referenced field pkey field name

Help me!
1

Hi.
We’re migrating from forest-express-sequelize to @forestadmin/agent .

Taking a look to the differences between the .forestadmin-schma.json generated with the old and the new agent, we saw a difference we would like to have a doublecheck about, with your help.

Our setup:

  • experiece_departures has many provider_notifications
  • provider notification has a primary key field uuid (which is an uuid, of course) and a fkey field id_experience_departure.
  • experience_departure has a primary key field id (integer).

In the .forestadmin-schema.json generated with the old agent, in the ExperienceDeparture collection, we can see this field:

{
    "field": "ProviderNotifications",
    "type": ["Number"],
    "defaultValue": null,
    "enums": null,
    "integration": null,
    "isFilterable": true,
    "isPrimaryKey": false,
    "isReadOnly": false,
    "isRequired": false,
    "isSortable": true,
    "isVirtual": false,
    "reference": "ProviderNotification.uuid",  <<<<<<<<<<
    "inverseOf": null,
    "relationship": "HasMany",
    "validations": []
  }

I the new file we can find this:

{
    "defaultValue": null,
    "enums": null,
    "field": "ProviderNotifications",
    "integration": null,
    "inverseOf": null,
    "isFilterable": false,
    "isPrimaryKey": false,
    "isReadOnly": false,
    "isRequired": false,
    "isSortable": true,
    "isVirtual": false,
    "reference": "ProviderNotification.id",  <<<<<<<<<<
    "relationship": "HasMany",
    "type": ["Number"],
    "validations": []
  }

It looks like the ProviderNotification.uuid reference have been renamed into ProviderNotification.id.
But we don’t have any ProviderNotification.id field there.

Since forest is woking correctly with the new agent, (as far as I can tell), we’re assuming this is a kind of convention you changed from old to new agent. May you please confirm this is the expected behaviour on your side? Or do you think that we’d better have some deeper check?

Thank you.
Matteo

2

Hello @Matteo,
Thanks for your question.
I dont think this is expected behaviour since you dont have an id column. I dont reproduce on my side.

Would you be able to share a bit more of your sequelize schema definition ?
Maybe a minimal reproducible example so that we can check if this is expected ?

Thanks,

@Nicolas.M

3

Hello @Nicolas.M
This is the significant part of the ExperienceDeparture model:

{
        id: {
          autoIncrement: true,
          autoIncrementIdentity: true,
          type: DataTypes.INTEGER,
          allowNull: false,
          primaryKey: true,
        },
// ...other fields...
}

This is the relationship from ExperienceDeparture to ProviderNotification:

    this.hasMany(models.ProviderNotification, {
      foreignKey: 'idDeparture',
      sourceKey: 'id',
    })

This is the relevant part of the ProviderNotification model:

{
        uuid: {
          type: DataTypes.UUIDV4,
          allowNull: false,
          primaryKey: true,
          defaultValue: () => uuidv4(),
        },
        idDeparture: {
          type: DataTypes.INTEGER,
          allowNull: true,
          field: 'id_departure',
        },
// ... other fields
}

This is the relationship from ProviderNotification to ExperienceDeparture:

    this.hasOne(models.ExperienceDeparture, {
      foreignKey: 'id',
      sourceKey: 'idDeparture',
    })

Now I’m investigating on our side the reason why we’re using a hasOne instead of a belongsTo relationship, but in the mean time you should have all the requested information.
Can you reproduce?

Thank you.
Matteo

4

Hi @Nicolas.M
We had an additional test replacing the hasOne relationship with the belongsTo relationship in our model.

Now this is the relationship from ProviderNotification to ExperienceDeparture:

    this.belongsTo(models.ExperienceDeparture, {
      targetKey: 'id',
      foreignKey: 'idDeparture',
    })

And the .forestadmin-schema.json file still contains a ProviderNotification.id in the reference key. But there’s no ProviderNotification.id field in our model :person_shrugging:
Here is the .forestadmin-schema.json file relevant part:

{
  "collections": [
    {
      "actions": [

      // ......

      ],
      "fields": [
        {
          "defaultValue": null,
          "enums": null,
          "field": "ProviderNotifications",
          "integration": null,
          "inverseOf": "Boat",
          "isFilterable": false,
          "isPrimaryKey": false,
          "isReadOnly": false,
          "isRequired": false,
          "isSortable": true,
          "isVirtual": false,
          "reference": "ProviderNotification.id",  <<<<<<<<<<<<
          "relationship": "HasMany",
          "type": ["Number"],
          "validations": []
        },

      // .....

      ],
      "icon": null,
      "integration": null,
      "isReadOnly": false,
      "isSearchable": true,
      "isVirtual": false,
      "name": "ExperienceDeparture",
      "onlyForRelationships": false,
      "paginationType": "page",
      "segments": [
        // ........
      ],
    },
  ],
}

Can you reproduce?

Thank you,
Matteo

5

Hello @Matteo,

I have indeed reproduced the case, thanks for the provided details.

From what I understand, it is simply due to to the fact that it is the “reverse” relation (parent hasmany children), so the id taken is the name of key from the standard relation (child belongsto parent ) through a foreign key pointing to ExperienceDeparture id.

Here is the code in the agent where this flow takes place.

In any case this doesn’t prevent the relation from working “both ways” as expected from within Forest Admin (navigating to related data, parents or children)

I hope this clarifies,

@Nicolas.M

1 Like
6

Thank you @Nicolas.M,

I understood that this difference between the old and new agent generated .forestadmin-schema.json file is not relevant :+1: Thank you.

After all, we thought this was a matter to double check with your help.
In this migration, we have a huge PR on our side. And honestly it’s impossible to perform an exhaustive user test of all our Forest features… :man_shrugging:

Therefore, we are heavily relying on the expected continuity from the old to the new agent.
For this reason, we are happy to check any potential issues with you, which could even arise from improper use on our part!

However, from what you’re explaining, this is not the case, so we’ll move forward confidently and check off this point as well.

We have a number of checklists in a developer/code perspective :sweat_smile: But we’re almost done :muscle:

Thank you very much,
Matteo