Migration to @forestadmin/agent - problems with not null + default value fields

Help me!
1

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

We have a Sequelize model with a field defined as follows:

  showCrew: {
    type: DataTypes.BOOLEAN,
    allowNull: false,
    defaultValue: true,
    field: 'show_crew',
  },

With the previous agent filed this used to be translated in the .forestadmin-schema.json file as:

    {
      "field": "showCrew",
      "type": "Boolean",
      "defaultValue": true,
      "enums": null,
      "integration": null,
      "isFilterable": true,
      "isPrimaryKey": false,
      "isReadOnly": false,
      "isRequired": true,  <<<<<<<<<<
      "isSortable": true,
      "isVirtual": false,
      "reference": null,
      "inverseOf": null,
      "validations": [{    <<<<<<<<<<
        "message": null,
        "type": "is present",
        "value": null
      }]
    }

With the new agent, this is what we see in the .forestadmin-schema.json file for the very same field:

    {
      "defaultValue": true,
      "enums": [],
      "field": "showCrew",
      "integration": null,
      "inverseOf": null,
      "isFilterable": true,
      "isPrimaryKey": false,
      "isReadOnly": false,
      "isRequired": false,  <<<<<<<<<<
      "isSortable": true,
      "isVirtual": false,
      "reference": null,
      "type": "Boolean",
      "validations": []     <<<<<<<<<<
    },

The problem here is that with the new agent the “not null” validation is lost (see the lines highlighted by arrows in the above code fragments).

As far as I can tell, with the new agent, whenever we have a field which is not null with a default value in our models, this problem arises.

We’re not sure, but maybe this is due to this code in the agent:

NB: this used to work correctly, instead, with the previous agent version.

May you please have a check?

Thank you.
Matteo

3

Hello @Matteo

Thank for your report.
As you pointed out, the new agent considers fields with default values as not required.

This shouldnt be an issue though, since either sequelize or your database knows how to fill in those values if missing, so from the frontend/user perspective, those fields can be considered not required.

If you still feel like it is an issue, could you please share some details about your user’s workflow regarding this point?

Thanks,

@Nicolas.M

4

Hi @Nicolas.M
Thank you for your reply.

Let me start by saying that passing to the new agent was expected to be seamless… That’s why, every time we encounter something different from the past, with the old agent, we ask. So thank you for your support.

In this particular case, the difference is that with the old agent, the user couldn’t select a not allowed value while editing an item (for example).
Now with the new agent the user can. And after that, the user receives an error when the form is saved. I don’t know why this error arises: we have a default value in the model!
But in the old agent version, thanks to the validation, we never hit this problem.

See this video: here we’re editing a record.
In the first part of the video, you can see the behaviour with the old agent version. In the second part the new agent version behaviour is shown (as you can see the null option is allowd in the boolean).

ezgif-4-3f7d8663e2

And this is the error shown by the new agent when the edit form is saved with the null value.

Screenshot 2024-09-26 at 14.58.03
Screenshot 2024-09-26 at 14.58.031032×330 15.7 KB

Thank you in advance for your feedback.
Matteo

PS: since I wrote about this listed field, here is the field definition in the sequelize model:

        listed: {
          type: DataTypes.BOOLEAN,
          allowNull: false,
          defaultValue: true,
        },
5

Actually, I’m afraid I have an idea… :innocent: please let me know if you think the following is correct :pray:

I think that this is Sequelize behaviour:

  • null: Validation error because allowNull is false.
  • undefined: The default value (true) is be used.

I think that choosing the null value in the boolean front-end widget, forces the field to be sent over as the null value. This can be easily seen in the developer tools of the browser: the null value is passed by forest in the payload.

But, in order to have the default value saved in the database by Sequelize, we should set somehow the value to undefined. But, AFAIK that’s not possible in the Forest frontend. We can only choose true, false or null.

Therefore, I think that this assumption is not correct:

If we consider “not required” this field, then if the user leaves it unfilled, a null value is sent to the backend, finally reaching Sequelize, which does not trigger the default value. Because, in the Sequalize perspective, a value have actually been passed is: the null value.
And null !== undefined: only undefined value is a “missing” value that triggers the default value in Sequelize.

Let me know your thoughts, please.

Thank you,
Matteo

1 Like
6

Hello. I think that your assumption is correct.

I will see how I can make a fix to improve this flow, either in the frontend or agent and let you know.

@Nicolas.M

1 Like
7

Thank you @Nicolas.M
If I may, I believe that the best and most suitable approach, in terms of seamless migration from old to new agent, would be to exactly replicate the previous behavior. :sweat_smile: :pray:

Thank you very much,
Matteo

8

Hi @Nicolas.M
As you know we’re in the middle of a migration and this is the last issue we’re dealing with. Therefore, we would like to be in sync with you in order to be able to plan our production release.

Thus I was wondering if there are any updates about this.

Thank you for your feedback,
Matteo

9

Hello @Matteo,

Sorry for the delay, we had a couple days off. A fix is almost ready on the agent side, but I will need a final round of internal review before we can move forward with it.
Thanks for your patience.

1 Like
10

Hi @Nicolas.M
No problem.

In the mean time, has anything moved forward regarding this fix? :pray:

Thank you,
Matteo

11

Hello,
The fix has been released to @forestadmin/datasource-sequelize@1.10.3
Please upgrade this dependency and let us know if it fixes your issue :pray:

1 Like