Performance issue

Hi Forestadmin team,
I have some performances issues when managing related data due to the way the requests are generated with Sequelize.

For example; between my collections users and crm_user_exchanges (it is the same thing with other related data), I have defined this:

db.addresses.belongsTo(db.users, { as: 'user', foreignKey: 'user_id' });

When using that model, it is working.
When I access my crm_user_exchanges collection inside related data section of my users collection,
a SELECT request is well generated by joining users LEFT OUTER JOIN crm_user_exchanges ON …
BUT all the columns of my users collection are used in that specific SELECT.
And because my users collection is very large, I am getting very poor performances.

With all my belongsTo relations referring to users, i have a lot of performance issues, because sequelize is generating all the requests with all the columns of each related data PLUS all the columns of the users collection.

Would id be possible to generate that specific SELECT without all the columns of the parent table, but only a selection of them?
Is there a way to do this?

I had tried already the following workaround:
By defining another model t_users which is only an abstract of the native table model, I have changed the model to:

db.addresses.belongsTo(db.t_users, { as: 'user', foreignKey: 'user_id' });

Note how the belongsTo association is now using t_users.

This works very well when accessing the crm_user_exchanges collection.
But then, I have a new issue:
When trying to create a new record in crm_user_exchanges , the id of the parent collection ( users here) is not automatically populated.

It’s happening when accessing related data of a given user record

To complete that ticket:
When browsing from the crm_user_exchanges root collection (not from users collection), I have a similar problem because of the belongsTo association to users .
When Forest is displaying the table, sequelize is generating a SELECT with all the columns of both collections, while I would need only the reference field of users to be returned by the query, and it is generating performances problems too.

So it would be a big improvement in performances if that could be fixed.
Thanks for letting me know of any update on this.

Hi Louis-Marie,

Thanks for following up on this performance issue. We haven’t been able to tackle this subject yet but we will keep you informed of our progress in this discussion.