The LIKE query operator is not implmented correctly.

[burkenyo]

The LIKE query operator is faked to call a limited set of string methods, and it does not implement the full syntax allowed by a real organization service. In a real organization service, the LIKE operator conforms (and is likely delegated) to the underlying MS-SQL LIKE operator:

• % matches a range of characters wherever it occurs.
• _ matches a single character.
• [X-Y] matches a character within the range of characters between X and Y, inclusive.
• [XYZ] matches any of the characters X, Y, or Z.
• [^X-Y] matches a character outside the range of characters between X and Y, inclusive.
• [^XYZ] matches a character other than any of the characters X, Y, or Z.

The LIKE query operator support in FakeXrmEasy must conform to a real organization service to mock all possible queries.

Here is an example of a LIKE predicate that works in a real organization service but fails in FakeXrmEasy.

FetchXML: <fetch> <entity name="invoice" > <attribute name="name" /> <filter> <condition attribute="name" operator="like" value="INV-[0-9][0-9][0-9]" /> </filter> </entity> </fetch>

example values for name:

• INV-4253
• INV-761
• INV-300
• INV-65D

FakeXrmEasy LIKE matches none, but real Organization Service LIKE matches “INV-761” and “INV-300”

Note: In Dynamics 365, the LIKE operator (and possibly other string operators) is case-insensitive.

[BetimBeja]

Hello @burkenyo , to mock all possible queries we must also handle the escaped % meaning [%].

Best regards, Betim Beja.

[jordimontana82]

Thanks for raising this @burkenyo

[burkenyo]

@BetimBeja, good point. Similarly, _, [, and ] can also be escaped as [_], [[], []], and these cases should be handled as well.

[BetimBeja]

Hello @burkenyo , I submitted PR #511 which should fix this issue. If you like you can add some unit tests to my PR so we can test all the cases you mentioned. If you are interested in Co-Authoring my Pull Request you can read my article on how to do it here.