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

[rle125]

After upgrading from SmartGWT 12.1 to 13.0, we see the following WARN log and our fetches don't filter properly:

WARN [com.isomorphic.jpa.JPADataSource] (https-jsse-nio-8443-exec-8) Field name: 'pojoId1' specified in criteria is non-persistent. Skipping.
WARN [com.isomorphic.jpa.JPADataSource] (https-jsse-nio-8443-exec-8) Field name: 'pojoId2' specified in criteria is non-persistent. Skipping.

The field it is referencing are the primary key fields in our POJO:

@Entity
@Table(name="BasePojo")
@Inheritance(strategy=InheritanceType.JOINED)
@DiscriminatorColumn(name = "pojoId1", discriminatorType = DiscriminatorType.INTEGER, length = 2)
public abstract class BasePojo  {

    @EmbeddedId
    private PojoKey key;

    @Column(name = "pojoId1", updatable = false, insertable = false)
    private int pojoId1;

    @Column(name = "pojoId2", updatable = false, insertable = false)
    private int pojoId2;
}

@Entity
@Table(name = "PojoA")
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn(name = "val", discriminatorType = DiscriminatorType.STRING)
public abstract class PojoA extends BasePojo {
    @Column(name = "val", nullable = true, length = 32)
    private String val;
   ...
}

@Entity
@Table(name="MyPojo")
@DiscriminatorValue(value="1")
@XmlDiscriminatorValue("1")
public class MyPojo extends PojoA {
    ...
}

@Embeddable
public class PojoKey implements Serializable {

    @Column(name = "pojoId1")
    private int pojoId1;

    @Column(name = "pojoId2")
    private int pojoId2;
}

@Entity
@Embeddable
@Table(name = "PojoB")
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn(name = "field", discriminatorType = DiscriminatorType.STRING)
@XmlAccessorType(XmlAccessType.NONE)
public abstract class PojoB extends PojoA{
   ...
}

@Entity
@Table(name="YourPojo")
@DiscriminatorValue(value="2")
@XmlAccessorType(XmlAccessType.NONE)
@XmlDiscriminatorValue("2")
public class YourPojo extends PojoA {
    ...
    @Embedded
    private PojoB pojoB;
}

And the ds.xml looks like:

<DataSource
        ID="myPojoDMI"
        serverConstructor="com.isomorphic.jpa.JPADataSource"
        beanClassName="app.MyPojo"
        dropExtraFields="true">
    <fields>
        <field name="pojoId1" type="integer" required="true" primaryKey="true"/>
        <field name="pojoId2" type="integer" required="true" primaryKey="true"/>
        ...
    </fields>
</DataSource>

<DataSource
        ID="yourPojoDMI"
        serverConstructor="com.isomorphic.jpa.JPADataSource"
        beanClassName="app.YourPojo"
        dropExtraFields="true">
    <fields>
        <field name="pojoId1" type="integer" required="true" primaryKey="true"/>
        <field name="pojoId2" type="integer" required="true" primaryKey="true"/>
        ...
    </fields>
</DataSource>

[Isomorphic]

Looks like this test case is actually just abstract..

For the actual DataSource in question, is autoDeriveSchema set? If it is, is the field public?

If it isn't, is the field declared explicitly in the DataSource?

[rle125]

I updated the test case to more accurately reflect our setup.

I added autoDeriveSchema=true and schemaBean="app.MyPojo" but get the same WARN logs:

WARN [com.isomorphic.jpa.JPADataSource] (https-jsse-nio-8443-exec-8) Field name: 'pojoId1' specified in criteria is non-persistent. Skipping.
WARN [com.isomorphic.jpa.JPADataSource] (https-jsse-nio-8443-exec-8) Field name: 'pojoId2' specified in criteria is non-persistent. Skipping.

The primaryKey fields are declared both the embedded PojoKey and the BasePojo classes as shown in the test case.

[rle125]

We tried removing the "updatable = false, insertable = false" annotations but receive errors stating they're already defined.

We tried modifying the ds.xml to reference key.pojoId1 and key.pojoId2 through xValuePath, but receive errors stating they're not found.

Is there a suggested approach to including these fields in a Criteria?

[Isomorphic]

Based on the information provided, we were unable to reproduce the issue locally. In our environment, fetching filtered data from the described data model appears to work as expected. Could you please share complete details about all the components involved? Ideally, a standalone use case with a minimal setup that showcases the issue would be highly helpful.

Filtering against such fields is fairly straightforward. Here's one of the criteria we used when attempting to reproduce the issue:

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

[rle125]

Are you getting the following log when performing the fetch?

WARN [com.isomorphic.jpa.JPADataSource] (https-jsse-nio-8443-exec-8) Field name: 'pojoId1' specified in criteria is non-persistent. Skipping.
WARN [com.isomorphic.jpa.JPADataSource] (https-jsse-nio-8443-exec-8) Field name: 'pojoId2' specified in criteria is non-persistent. Skipping.

I assume these are because of the following annotation parameters?

@Column(...updatable = false, insertable = false)

However, removing updatable and insertable results in:

Caused by: org.hibernate.MappingException: Repeated column in mapping for entity: app.BasePojo column: pojoId1 (should be mapped with insert="false" update="false")

[rle125]

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

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

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

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]

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]

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]

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]

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]

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.