[rle125]

Looks like the message occurs when I have more than one datasource that extends BasePojo loaded. See updated sample in first post.

Field name: '...' specified in criteria is non-persistent. Skipping.

<script src="lncs/sc/DataSourceLoader?dataSource=myPojoDMI,yourPojoDMI">

Let me know if you see the same behavior when loading 2 datasources.

[Isomorphic]

We have added an additional entity and its associated data source to the setup, as described in your updated first post. However, we are still unable to reproduce the issue. No warnings are displayed, and the JPA query generates as expected:

select __MyPojo from _MyPojo __MyPojo  where (__MyPojo.pojoId1 > :p0 and __MyPojo.pojoId1 is not null)

[rle125]

I updated the example with another base class that was missing from the 2nd entity.

I also emailed a link to an updated zip file with the actual entities, base classes and datasources.

[Isomorphic]

We’ve received the updated ZIP file with an additional entity extending a common parent class. However, this does not help us reproduce the issue. The JPA query still behaves as expected, with the appropriate filtering applied.

To assist you more effectively, we kindly request a complete standalone use case or any explicitly requested information that would help us replicate the problem. Specifically, we need:
- A set of entities that we don’t need to strip or modify. These should be functional within the context of a simple filtered fetch request. (Previously, we received functional Pojo entities but without additional details. We also couldn’t find a functional set of entities in the ZIP archives you shared.)
- Datasource configurations for the entities mentioned above (these we have received).
- A code snippet that issues the fetch request against this data model, leading to the problematic warnings and incorrect filtering. This might include client-side code creating the request or server-side code programmatically generating a DSRequest and executing it. (We haven’t received this from you yet, so we’re currently making assumptions, which isn’t productive.)

Ideally, providing all of the above in a well-structured standalone use case will help us reproduce the issue on our side and enable a faster resolution. Thank you for your help.