Enable Where clause to generate $filter query options for key predicates

[KenitoInc]

Issues

This pull request fixes issue #851 .

Description

The Where clause generates a Uri with a $filter where we have a non-key predicate e.g
var books = dsc.Books.Where(b => b.Title == "B1"); creates the Uri below
https://serviceRoot/Books?$filter=Title eq 'B1'
In this case, if the Title is not found, the query will return an empty collection.

When we have a key in the predicate, the Where clause generates a Uri with a ByKey resource path e.g
var books = dsc.Books.Where(b => b.Id == 1); creates the Uri below
https://serviceRoot/Books(1)
In this case, if the Id is not found, the query will throw an exception.

By design Where should not throw an exception whenever the predicate does not match any value/element in the source collection.

Solution

Changing the current behavior will be a breaking change. So I have added a DataServiceContext.KeyComparisonGeneratesFilterQuery property which is false by default.
So if a customer want to ensure that a Uri with a $filter query option is generated for key predicates in the Where clause, they need to set the KeyComparisonGeneratesFilterQuery property as true

Container context = new Container(uri);
context.KeyComparisonGeneratesFilterQuery= true;

Checklist (Uncheck if it is not completed)

• Test cases added
• Build and test with one-click build and test script passed

Additional work necessary

If documentation update is needed, please add "Docs Needed" label to the issue and provide details about the required document change in the issue.

[odero]

Considering how long this issue has existed I'm wondering if it might be a breaking change for people who might rely on this behaviour?

[KanishManuja-MS]

@KenitoInc Can you please rebase the PR and get someone to approve it from the Nairobi team? #Closed

[KenitoInc]

@KanishManuja-MS I need to redesign a small feature so as not to break exisiting functionality. In the meantime I have removed this PR from v7.7 milestone #Closed

[gathogojr]

LGTM. I'd argue that in the next major version we shouldn't make this optional. We should just make it generate the $filter expression

[mikepizzo]

            if (!input.UseFilterAsPredicate)

trying to understand how UseFilterAsPredicate relates to the new keyComparisonGeneratesFilterQuery. Do they do the same thing, but are set in different places? In what cases/why do we set UseFilterAsPredicate today? Would we have the same logic if line 278 was !input.UseFilterAsPredicate && !keyComparisonGeneratesFilterQuery, and removed the additional checks below? #Resolved

---

Refers to: src/Microsoft.OData.Client/ALinq/ResourceBinder.cs:278 in 8368f37. [](commit_id = 8368f37, deletion_comment = False)

[mikepizzo]

🕐

[mikepizzo]

@kennedy - See a couple comments. If we can get those resolved I'd love to merge. Also, please mark other comments as resolved as appropriate (i.e., in codeflow) to make it easier to track status of comments. Thanks! #Resolved

[KenitoInc]

            if (!input.UseFilterAsPredicate)

trying to understand how UseFilterAsPredicate relates to the new keyComparisonGeneratesFilterQuery. Do they do the same thing, but are set in different places? In what cases/why do we set UseFilterAsPredicate today? Would we have the same logic if line 278 was !input.UseFilterAsPredicate && !keyComparisonGeneratesFilterQuery, and removed the additional checks below?

Refers to: src/Microsoft.OData.Client/ALinq/ResourceBinder.cs:278 in 8368f37. [](commit_id = 8368f37, deletion_comment = False)

@mikepizzo
UseFilterAsPredicate is used create a $filter query option when we have both key and non-key predicates in the expression.
However in scenarios where we have only a key predicate in the expression, we generate a Uri with a ByKey resource path. KeyComparisonGeneratesFilterQuery allows us to specify if we want a $filter or ByKey.

We can clean up the logic so as to work well with both. #Resolved

[mikepizzo]

Considering how long this issue has existed I'm wondering if it might be a breaking change for people who might rely on this behaviour?

---

In reply to: 406936949 [](ancestors = 406936949)

[mikepizzo]