You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
The text was updated successfully, but these errors were encountered:
amoffet
changed the title
MetadataBackedField#getPath seems to be inefficient for field names that are not "simple"
MetadataBackedField#getPath seems to be very inefficient for field names that are not "simple"
Jul 6, 2021
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:
trying to construct a PropertyPath. The root call is:
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>):
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:
The text was updated successfully, but these errors were encountered: