[Isomorphic]

We've added this to our local setup, but the issue still does not reproduce.

[rle125]

I think the reason is we're embedding a class that also extends the base class:

public class YourPojo extends PojoA {
   ...
   @Embedded private PojoB pojoB;
}

I've updated the example in the 1st post.

[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.

[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 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]

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]

Generally, the client-side should not influence the server-side at such a low level as the JPA data model. However, there appears to be something unique about the fetch request your app sends from the client-side, which triggers warnings and results in incorrect filtering. To diagnose the issue, you could either replicate the exact request or partially integrate client-side code into your standalone use case to showcase the problem.

On a related note, could this be a class-loading issue? Is it possible that multiple versions of your entity classes exist on the classpath, causing the wrong ones - potentially those missing certain field declarations - to be loaded at runtime?

Regarding "multiple Datasource loading," while the exact meaning is unclear, it is generally safe to load multiple data sources as long as documented approaches are followed.

[rle125]

After creating a standalone test case, I do not see the message:

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

I didn't change any server-side code, I just commented out client-side code.

Is there something on the client-side that could result in that message?

Could multiple Datasource loading result in that message?

[Isomorphic]

Thank you for the information you’ve provided. While it does help us understand more about the context, we’re still unable to see the complete picture needed to reproduce the issue.

To avoid exposing details about your setup, we currently lack descriptions of the requests sent from the client or the criteria applied to specific data sources. Since server logs don’t include request payloads, we’re left making assumptions, which is unproductive — especially considering we’ve already attempted this approach.

As agreed, we’re still waiting for the standalone use case you mentioned you would provide.

In your original post, you shared an example based on the MyPojo entity (with BasePojo/PojoA/PojoKey helpers) and the myPojoDMI data source. This example produces WARN log statements for the pojoId1/pojoId2 fields, leading to incorrect filtering. This suggests that you may already have a working (semi-)standalone use case that demonstrates the issue. Could you please share it with us?

[rle125]

I sent the complete server log, datasource and actual entities/ds.xml files over email. Please let me know if you need anything else.

[Isomorphic]

Did you enable DEBUG level logging for the mentioned categories? To do so, you need to add the following categories to your log4j configuration:

    <category name="com.isomorphic.jpa">
        <priority value="DEBUG" />
    </category>

    <category name="com.isomorphic.annotations">
        <priority value="DEBUG" />
    </category>

After enabling this, you should start seeing more detailed logs about the DataSource initialization process. Specifically, you’ll see information about what is read from the entity annotations. For example:

DEBUG JPADSGenerator - Instantiating class com.isomorphic.test._MyPojo
DEBUG DataSourceAnnotations - Generating data source '_MyPojo' for class com.isomorphic.test._MyPojo
DEBUG DataSourceAnnotations - Read DSFields from class
DEBUG DataSourceAnnotations - Generating data source '_PojoA' for class com.isomorphic.test._PojoA
DEBUG DataSourceAnnotations - Read DSFields from class
DEBUG DataSourceAnnotations - Generating data source '_BasePojo' for class com.isomorphic.test._BasePojo
DEBUG DataSourceAnnotations - Read DSFields from class
DEBUG DataSourceAnnotations - Generating data source 'Object' for class java.lang.Object
DEBUG DataSourceAnnotations - Fields are annotated.
DEBUG DataSourceAnnotations - Generating field 'key' of type com.isomorphic.test._PojoKey
DEBUG DataSourceAnnotations - Property with embedded fields. Generating subproperties for type com.isomorphic.test._PojoKey
DEBUG DataSourceAnnotations - Generating data source '_PojoKey' for class com.isomorphic.test._PojoKey
DEBUG DataSourceAnnotations - Read DSFields from class
DEBUG DataSourceAnnotations - Generating data source 'Object' for class java.lang.Object
DEBUG DataSourceAnnotations - Neither fields nor methods are annotated. Using fields.
DEBUG DataSourceAnnotations - Generating field 'pojoId1' of type int
DEBUG DataSourceAnnotations - Field configuration generated: {canEdit=true, name=pojoId1, length=255, type=integer, required=false}
DEBUG DataSourceAnnotations - Generating field 'pojoId2' of type int
DEBUG DataSourceAnnotations - Field configuration generated: {canEdit=true, name=pojoId2, length=255, type=integer, required=false}
DEBUG DataSourceAnnotations - Updated subproperty field configuration: {canEdit=true, name=key_pojoId1, length=255, useJoin=false, valueXPath=key.pojoId1, type=integer, required=false, primaryKey=true}
DEBUG DataSourceAnnotations - Updated subproperty field configuration: {canEdit=true, name=key_pojoId2, length=255, useJoin=false, valueXPath=key.pojoId2, type=integer, required=false, primaryKey=true}
DEBUG DataSourceAnnotations - Subproperties generated.
DEBUG DataSourceAnnotations - Generating field 'pojoId1' of type int
DEBUG DataSourceAnnotations - Field configuration generated: {canEdit=false, name=pojoId1, length=255, type=integer, required=false}
DEBUG DataSourceAnnotations - Generating field 'pojoId2' of type int
DEBUG DataSourceAnnotations - Field configuration generated: {canEdit=false, name=pojoId2, length=255, type=integer, required=false}
DEBUG DataSourceAnnotations - Neither fields nor methods are annotated. Using fields.
DEBUG DataSourceAnnotations - Generating field 'val' of type java.lang.String
DEBUG DataSourceAnnotations - Field configuration generated: {canEdit=true, name=val, length=32, type=text, required=false}
DEBUG DataSourceAnnotations - Neither fields nor methods are annotated. Using fields.

What we mean by "loaded DS config" is essentially the DataSource instance that your application uses after initialization. For example on the client-side you could examine that:
- By using the isc.DataSource.load() client-side API and inspect the loaded DataSource object
- By calling the DataSourceLoader servlet directly
- By using the isomorphic:loadDS JSP tag and checking the result in web page source by looking for the code "isc.DataSource.create({...ID:"myPojoDMI"...})".

We are specifically interested in the fields that the DataSource contains after initialization. If you have access to the DataSource instance on the server, you can retrieve its fields programmatically using the getFieldNames() and getField(name) DataSource server-side APIs.

Let us know if you encounter any issues or need further assistance.

It would also be helpful to review the complete log, starting from the DataSource initialization and ending with the mentioned warnings and JPA queries for the fetch requests that do not filter properly. While this is best done with a standalone use case, if you can identify these sections in your current logs, they could still be potentially helpful in the meantime.

[rle125]

DEBUG doesn't provide much additional information:

2025-01-08 11:57:20,905 DEBUG [com.isomorphic.jpa.JPADataSource] (https-jsse-nio-8443-exec-11) Creating EntityManager and starting transaction.
2025-01-08 11:57:20,905 DEBUG [com.isomorphic.jpa.JPADataSource] (https-jsse-nio-8443-exec-11) Executing fetch.
2025-01-08 11:57:20,906 WARN [com.isomorphic.jpa.JPADataSource] (https-jsse-nio-8443-exec-11) Field name: 'pojoId1' specified in criteria is non-persistent. Skipping.
2025-01-08 11:57:20,906 WARN [com.isomorphic.jpa.JPADataSource] (https-jsse-nio-8443-exec-11) Field name: 'pojoId2' specified in criteria is non-persistent. Skipping.
2025-01-08 11:57:20,906 DEBUG [com.isomorphic.jpa.JPADataSource] (https-jsse-nio-8443-exec-11) Query s/tring: select _MyPojo from MyPojo _MyPojo
2025-01-08 11:57:20,908 DEBUG [com.isomorphic.jpa.JPADataSource] (https-jsse-nio-8443-exec-11) Committing current transaction.
2025-01-08 11:57:20,912 DEBUG [com.isomorphic.jpa.JPADataSource] (https-jsse-nio-8443-exec-11) Releasing entity manager.

Can you let me know where to find the "loaded DS configuration"?

I'll work on providing a standalone use case.

[Isomorphic]

Apologies for the delayed response. This issue was assigned immediately, but we missed your follow-up.

We are still unable to reproduce this behavior locally. As mentioned earlier, we are using the following criteria:

{_constructor: "AdvancedCriteria", fieldName: "pojoId1", operator: "greaterThan", value: 1}

This generates the following JPA query:

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

We are using the exact same entities and ds.xml configuration that you provided, so there must be another factor at play.

You might try enabling DEBUG logging for the categories "com.isomorphic.jpa" and "com.isomorphic.annotations" - this could potentially reveal some useful clues. Additionally, could you share how the loaded DS configuration looks? Does it contain all the expected fields, specifically "pojoId1" and "pojoId2"?

Also, providing a complete standalone use case often reveals significant details. If nothing else helps, we would appreciate it if you could provide one. Thank you.

[rle125]

Checking to see if the latest updated test case from my original post is sufficient for you guys to troubleshoot, or if you still need more information.

[rle125]

I updated the original data model in my first post with all the JPA annotations used as well as a second abstract class.