System.ArgumentException on Associate about fake-xrm-easy HOT 8 CLOSED

Ok so I investigated further and I'm not quite sure, whether we really have to change this behaviour, since simply changing the names that are initialized in the Faked Relationship did not destroy the tests for me. It might get relevant however, if the intersection entity is queried directly.

@jordimontana82:
I found out, that my queries fail, if I have Conditions in my link entities.
The lambda expression forms a condition like this:

Param_0.Attributes.ContainsKey("[IntersectionEntity].[ConditionField]")

So when I inspect the objects that the query includes before applying the lambda, I see, that the property with the name of the intersection entity is null.
I guess that the lambda targets this lookup field, so it might be necessary to fill it on associate, too.

Edit: So it seems that there might be even more handled incorrectly.
The Lambda Expression handles this as if it was a plain field in the query entities, e.g. it tries to get its value and to parse it as guid.
This field however is an enumerable, so even if we populated, the query would still be wrong...

from fake-xrm-easy.

Could you add a test method to reproduce this? I'll have a look whenever I have a chance :)

from fake-xrm-easy.

Hey @jordimontana82,

Thanks for your response.
I found the issue: Our code was doing natural joins, while FakeXrmEasy for now just processes inner and left outer joins. Other joins are just stepped over.
As a fix I added the natural join to the supported join statements, however it is currently processed like the inner join.
In addition to that, I thought it might be useful, if we throw exceptions on not supported join statements, so that issues can be found faster.
I'll send a PR.

Kind Regards,
DigitalFlow

from fake-xrm-easy.

Cool! 👍

Thanks a mill

from fake-xrm-easy.

My pleasure :)
Do you think the duplicate key exception when adding a relationship with identical attribute1 and attribute2 is an issue?
In my tests I just renamed the attributes that I added in the faked relationship.
As long as you don't want to directly query the intersect entity for those attributes, it should not be an issue, but if you do, than that's a problem.
I thought of prepending an "attr1" and "attr2" tag in front of the attribute names when creating the intersection entity record and prepending it for every request that targets the intersect entity, but not sure, if its worth the effort...

from fake-xrm-easy.

The only scenario I can think of might be for N:N self referential relationships maybe?

from fake-xrm-easy.

I think so. Should we then close this issue?

from fake-xrm-easy.

Yeah, let's close it and we can reopen if such scenario happens in future.

from fake-xrm-easy.