Description
spring-data-r2dbc version 1.2.9
Given a field name such as person_change_id QueryMapper#forName will iterate over the parts of the path:
person
change
id
trying to construct a PropertyPath. The root call is:
private PersistentPropertyPath<RelationalPersistentProperty> getPath(String pathExpression) {
try {
PropertyPath path = this.forName(pathExpression);
return this.isPathToJavaLangClassProperty(path) ? null : this.mappingContext.getPersistentPropertyPath(path);
} catch (PropertyReferenceException | MappingException var3) {
return null;
}
}
The method above will be called for the first part of the path (person).
The owning type (entity) is "asked" if it has a property of that kind ( see constructor PropertyPath<String , TypeInformation, List>):
TypeInformation<?> propertyType = owningType.getProperty(propertyName);
if (propertyType == null) {
throw new PropertyReferenceException(propertyName, owningType, base);
} else {
If it does not (the owning type has personChangeId and not person), it throws the exception which is converted to a "null" in QueryMapper (as shown in the code at the top of this issue).
Each time a Query of the same kind is executed, this same code path is followed. (SELECT * FROM changes WHERE person_change_id = (any number)). The field we are trying to construct metadata for comes from the select list. In my application, I'm seeing hundreds of thousands of exceptions in a few minutes.
Admittedly, I haven't been able to dig deeply enough yet to understand what condition yields a good property path in the MetadataBackedField, but it seems quite specialized. No field in my simple entity meets the criteria:
id BIGSERIAL PRIMARY KEY,
person_change_id BIGINT NOT NULL,
group_id VARCHAR(255) NOT NULL,
person_count_key VARCHAR(255) NOT NULL,
create_date TIMESTAMP NOT NULL default current_timestamp,
update_date TIMESTAMP NOT NULL default current_timestamp
But I will get 5 exceptions from a simple query (each of which are converted to null).
See picture of stack trace for additional context:
This is the dominant exception in my application: