MetadataBackedField#getPath seems to be very inefficient for field names that are not "simple"

[amoffet]

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:

[mp911de]

See also spring-projects/spring-data-mongodb#2862 and spring-projects/spring-data-mongodb#3620

[amoffet]

I'm interested in knowing how the process goes from here. It looks like it's stalled. Does the team consider these things on iteration boundaries?

[amoffet]

Like to bring this to the front again for consideration. It's a real performance killer.

[mp911de]

Superseded by spring-projects/spring-data-commons#2837