Support for expand query when filtered on collection field using lambda

[Dolly-Yadav]

For version 2.1.1, the following queries was tried for a Products entity, where we expand ProductDetails with at least one ProductDetailSources as catalogue.

http://localhost:8080/odata/Products?$expand=ProductDetails($filter=ProductDetailSources/any(p:p eq 'catalogue')) http://localhost:8080/odata/Products?$filter=ProductId eq 358&$expand=ProductDetails($filter=ProductDetailSources/any(p:p eq 'catalogue'))

Query explanation

• Products is an entity. It contains a navigational property to ProductDetails.
• ProductDetails is another entity.
• ProductDetails contains ProductDetailSources which is a collection of Strings.

Issue A NullPointerException occurs while constructing query. In JPAExistsOperation.get() the query shows null in this.getExistsQuery().query(). Further analysis shows that pathList of JPAExistsOperation.determineAssociations() is empty for our above sample queries.

Closest analogous query using entities in this repo Organizations?$expand=SupportEngineers($filter=InhouseAddress/any(p:p/Building eq '1'))

Could you please help us confirm whether the feature of expanding a query, when filtered on a collection field using lambda, is supported?

[dbhandari555]

The below testcase reproduces the above scenario. The testcase fails with org.opentest4j.AssertionFailedError: {"error":{"code":null,"message":"OData Library: An exception without message text was thrown."}} but if a breakpoint is put in JPAExistsOperation.java class on determineAssociations method, the source of NPE can be figured.

  @Test
  void testExpandWithFilterOnCollectionField() throws IOException, ODataException {
    final IntegrationTestHelper helper = new IntegrationTestHelper(emf,
            "Organizations?$expand=SupportEngineers($filter=InhouseAddress/any(p:p/Building eq '7'))");
    helper.assertStatus(200);
  }

[dbhandari555]

@wog48 The fix for this bug has been proposed as part of PR https://github.com/SAP/olingo-jpa-processor-v4/pull/329. The code change is made to JPAExistsOperation.java class and does 2 things:

1. Add isCollection check when one/more of the resource parts have navigation property
2. Combine the hasNavigation and hasCollection checks under a single if and remove repetitive code. 2 Test cases have been added to make sure the code works as expected.

[spatanjali]

@wog48 Would you please be able to share your review of the PR. We will be happy to incorporate any changes/comments to support having the fix merged back and released.

[wog48]

Issue shall be solved with 2.1.3. In case the problem still exists, please reopen this issue. Thanks for supporting.