Ok, sounds good, thanks Alban.
@Alban_Bertolini I cleaned all the broken entries in the database, so that all relationships can be established. Unfortunately, the error still persists.
1 Like
It’s been 21 days and the bug hasn’t been fixed. This is also blocking the release of the new client for us.
The workaround you suggested (with client__manyToOne:_id) does not work. Could you think of another one? For example, adding a relationship to MyCollection in order to make it compute what’s needed?
Or might you have any indication on how long it will take to fix the bug?
Thanks for your efforts - I really appreciate it.
Hello,
The fix is in review, and will be merged today, but maybe you can try it before the merge:
Maybe you will encounter an error again…
The documentation is not ready, but you can add an externalDependencies path in the addField options:
collection.addField('product', {
....
externalDependencies: [{collectionName: 'legalProductOrders_items', path: 'legalProductItem:legalProduct:nameEN'}],
1 Like
Thanks @Alban_Bertolini, I will try it out as soon as there is an npm version I can point towards. I guess, now, that’s not possible yet. But if it gets merged today, that’s fantastic.
To try, You can override the forest dependencies in your packages.json: package.json | npm Docs.
Yes, I can also simply change the version in package.json altogether.
Yet, the thing that blocks me from trying your PR at the moment is that I don’t know which datasource-customizer version to point towards - at least as long as the fix is not released.
Or do you see a way to achieve this?
Yes you can put the agent-nodejs repository with my branch as dependencies. A tutorial: Use Github branch as dependency in package.json | by Jon Church | Medium
Ok, but unfortunately this downloads the source files and not the distribution, so the build breaks on my repository. I saw, that the PR is reviewed, so I’ll wait for it to be merged and released.
Hi @David_Roegiers,
Thanks for the intensive agent test and the related feedback.
This topic is actually very sensitive as a patch would make our API evolve and we want to be collectively sure that it goes in the right direction with intelligible methods or attributes names.
We must take the more time to discuss this and design the best future for the agent on this specific use case.
We understand that you need to deliver value and the only “workaround” we have in mind would be to build a few stuff manually; to retrieve nameEN values manually after the list call, not to use the list method te retrieve the items,… There is no great workaround, but that is the direction you should consider to deliver quickly.
Thanks for you extensive patience.
Hi @arnaud
Thanks for your feedback!
To be honest, after giving it some thought, I am happy, that the solution with externalDependencies is being pulled back. The naming is somewhat confusing. Moreover, from an external point of view, it just makes the addField API complexer without offering value for the consumer. It is redundant with the second argument of the list call, so it merely patches an underlying issue and unnecessarily involves the module user. From the outside perspective, it’s bad design…
That being said, I can imagine, that building a working dependency tree, which correctly prioritizes computed fields and relationships - especially for the pattern I introduced here above (i.e. list call of relationships of a different collection within getValues of a computed field), must be quite a challenge … Is it even possible to fix this “under the hood”?
Anyway, I just implemented the workaround by loading in all the data with separate list requests and then reconstructing the relations. It works for us now. 
Shall we keep this issue open until a fix is released, so I can clean up the workaround in the future? No urgency for me.
3 Likes
Great to read that you are aligned on the fact that we need an elegant patch for this issue, and you have a temporary solution for your use case.
Yes, let’s keep the topic open.
We’ll get back to you and ideally close it once the definitive solution is released and approved on your end.
1 Like
In another attempt, I tried making a many-to-many relationship between legalProductOrdersand legalProductItems, in order to call that relationship through the dependencies attribute of addField.
This would avoid the need to call a collection list functions with its corresponding relations in the getValues function.
But, I noticed it is not possible to call a many-to-many relationship in a projection. Right? If this can be built in, then there would be no need to solve the scenario I introduced here above.
2 Likes
Hello,
Yes it is not possible to call a many to many in a projection.
1 Like
Fast forward one year. Is there an update on this?