Custom Field Values of Nested Model Not Loading

Help me!
1

Feature(s) impacted

I included a repo to illustrate my problem:

The custom field of a nested model is not loading, when placed as a reference for that nested model.

Observed behavior

With my repo:

  1. in the layout, set fullAddress as the reference field for “clients_address”.
  2. Create a new client
  3. For that client fill in the address
  4. Go to that client’s detail view.

You will should see the address relationship is falsely displayed with “null, null null”

Expected behavior

Instead I would expect the relationship to appear with “Street Nr, Postal Code Municipality”

Failure Logs

None

Context

Can be extracted from the repo.

2

Hello @David_Roegiers,

Thanks for reaching out and for the repo :raised_hands:

Sorry to hear you’re facing this inconvenience.
I’m going to try to reproduce on my side and I’ll get back to you.

Cheers!

1 Like
3

@anon34731316

You will see, in my repo, that I have configured the flattener for the mongoose model as follows:

clients model

...
address: {
 street: string,
 municipality: string
},
...

clients flattenOptions

{
    asModels: ['address']
}
...

Are non-array nested object fields in the data model, allowed to be flattened as models?

In that case, sorry for the false bug report. I did not get it from your documentation, that this is a no-go. Anyway, that is what I did and might the reason why we are seeing this behaviour. Moreover, it causes another bug on creation of a new address. If this is indeed not supported behaviour, maybe might be cool to implement a fail-safe informing the developer through an error, that this sort of configuration is not possible, i.e. only array fields may be configured asModels.

FYI @jeffladiray

5

Hello @David_Roegiers,

I’m taking over this subject. Thanks a lot for the minimal example reproducing your issue. I’ll investigate on my side and get back to you.

1 Like
6

For information, I’m working on a fix on your first problem regarding the computed field “full address” not being correctly retrieved when used as a reference field.

Using asModels on a non-array field should be supported because it’s not a lot different from using it on array fields. Right now it seems to have some limitations, but we’ll fix them.

I’ll work on a second fix regarding the creation when the first one will be released.

Please note though that address creation will only be possible on an existing client: as addresses are attached to client objects, it won’t be possible to create an address first, and then a client.

7

Okay, thanks @GuillaumeGautreau.

That’s good to hear. It would be helpful to use asModels on a non-array field. I will apply this to visually improve the structure of the Details view of field-heavy collections.

I’ll wait for your fixes then.

That makes sense. Is there a way to programmatically avoid this option to appear in the UI? Our operators will find it and then report this as a bug.

8

Hello @David_Roegiers,

We released @forestadmin/datasource-mongoose@1.5.15 fixing the issue with computed fields. You can upgrade to this version and use computed fields as expected.

Regarding the possibility to hide the address creation, I would suggest to not give the right to create addresses to users. You can remove this possibility in the roles tab in your project settings (once deployed in production or on a remote environment).

It might be useful though to create addresses along with clients, which is possible with the option … asFields but at the moment you cannot use both asFields and asModels at the same time on the same field.

I think it might be possible using the flattener plugin (see the docs here) in addition to asModel. But right now we have the same creation bug than the one we need to fix.

I’ll let you know once done.

2 Likes
9

We released @forestadmin/datasource-mongoose@1.5.17 that fixed the issue with record creation and retrieval.

Could you please give it a try?

10

Thanks @GuillaumeGautreau

I’m just waiting for this fix to be merged, and then I will try them both out in the afternoon, if it’s ready by then.

11

@GuillaumeGautreau

Sorry for the late reply, I was focused on some other threads.

So, I’m running @forestadmin/datasource-mongoose:1.5.19.

There is a non-array nested object field of my MongoDB data model, called x. I added x to the asModels array of the built-in field flattener for that model.

Unfortunately, when I navigate to the computed record, which corresponds to that field x (detail view), the server freezes, i.e. the HTTP request stalls.

Any idea why this might be the case?

12

Let me add some more information, on top of the analogy I described earlier (with the flattened model field x):

This FA server request works:
http://localhost:3310/forest/parent_x?timezone=Europe%2FZurich&fields[lawyers_billing]=_id%2CbexioContact%2CbexioContactId%2Cparent%2CstripeCustomerId&fields[parent]=fullName&page[number]=1&page[size]=15&sort=-_id

While, this FA server request stalls:
http://localhost:3310/forest/lawyers_x/64a1eca47c0ce8420edc95fc.x?timezone=Europe%2FZurich

The logs don’t say anything, and I haven’t customized the lawyers_x collection.

:thinking:

13

It’s not much information, but maybe you can suggest me a line number in the distribution, where to put a breakpoint (js, not ts) and share some variable data?

14

It seems, that the issue might be coming from something else. I’m investigating and will get back to this thread.

15

So, the faulty behaviour is happening, if I upgrade @forestadmin/datasource-mongoose from 1.5.15 to 1.5.16. I once saw a MongoPoolClearedError, but I am not certain if this is the culprit.

In this situation, I can not upgrade past 1.5.15 to test the new functionality, so we would need to fix this, before I can mark this issue as solved.

16

So, I can confirm, that this is working with version 1.5.15 and will mark this issued as Solved.

Nonetheless, I can’t upgrade beyond that, which is OK for me now, since I don’t have the issue about the field creation any more.

Still would be great if this freezing behaviour gets tackled at some point.

17

Hello @David_Roegiers,

Is it possible to share a repository that reproduces this bug, as you did with the previous one? On my side when I navigated to records everything worked smoothly so I would need more info to reproduce the issue.

Thanks

18

Hello @GuillaumeGautreau

In order to create a minimal reproducing repository, I want to quickly test the code in a ForestAdmin UI.

Setting this up as a ForestAdmin configuration, quickly, has been quite cumbersome so far for the following reasons:

  • I don’t want this test to mess with the layout of my existing project.
  • If I create a new ForestAdmin project, it seems very difficult to get past the onboarding process in the UI, which is the main approach I know.

What would you recommend, is the fastest way to get a FA server running with env vars, so I can test it out in the UI.

Thanks!

19

Using the following command, you’ll create a project and the file structure for your db:

forest projects:create reproduce-bug -H localhost -P 3333 -c mongodb://localhost:27017/bug

With:

  • reproduce-bug being your new project name (chose one that is not already taken)
  • -P is the port number of your new agent
  • -H is the host name of this new agent
  • -c contains the connection string to your DB that will help reproduce the issue. This DB is introspected to create the corresponding Mongoose schemas.

You need to be logged in first, if it’s not the case, run forest login to authenticate your command line executable locally.

20

Thanks. Mongodb is running locally on 27017, but I get the following error when setting up the project:

× Cannot connect to the database due to the following error:
× {"name":"MongoServerSelectionError","reason":{"type":"Single","setName":null,"maxSetVersion":null,"maxElectionId":null,"servers":{},"stale":false,"compatible":true,"compatibilityError":null,"logicalSessionTimeoutMinutes":null,"heartbeatFrequencyMS":10000,"localThresholdMS":15,"commonWireVersion":null}}
21

forest-cli/4.2.0 darwin-arm64 node-v18.16.1

and

mongo localhost:27017/bug

works properly