Please try to add the client__manyToOne:_id relation field in the dependencies properties in your addField method. It will force the field to be computed after the relation.
If you have an error again, is the error always the same? If it is, you have probably a cycle dependency.
A field needs a computed relation to be computed and the relation needs this same field to be computed .
Ty for the feedback.
I’ll get to work on fixing the bug as soon as possible, and then, if the problem persists on your side, we’ll do a pair programming session.
@Alban_Bertolini I cleaned all the broken entries in the database, so that all relationships can be established. Unfortunately, the error still persists.
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 @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.
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.
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.
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.
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 withingetValues 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.
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.