Auto-generated R2DBC queries with snake-case properties consume excessive memory

[trevoreckersley]

We have a project using R2DBC. For one of our entity objects, we have been relying on Spring's automatically generated queries for looking up objects. Simplified example:

@Table("my_table")
public class MyEntity {

  @Id
  @Column("id")
  Long id

  @Id
  @Column("reservation_id")
  Long reservationId

  // getters, setters, equals, and hash codes
}

@Repository
public interface MyRepository extends R2dbcRepository<MyEntity, Long> {
  Flux<MyEntity> findByReservationId(Long reservationId);
}

Lately though, we've noticed garbage collection issues with the application. On further investigation, we found that a lot of the memory being allocated has come from org.springframework.data.mapping.PropertyReferenceException instances being thrown by calls to org.springframework.data.mapping.PropertyPath#from(java.lang.String, org.springframework.data.util.TypeInformation<?>). These exceptions get swallowed by org.springframework.data.r2dbc.query.QueryMapper.MetadataBackedField#getPath, so the query ends up completing, but the exception is thrown every time these queries are made (which is frequent), which leads to a lot of memory churn.

Something about all of this seems broken. It doesn't seem like every attempt to run that query should run that code path to throw an exception. Something should either be catching and remembering the failure (to not do it every time), or it shouldn't be asking for something that should raise this issue in the first place.

Some other items of note:

1. When PropertyPath#from(java.lang.String, org.springframework.data.util.TypeInformation<?>) is called, the string being passed in is "reservation_id". It gets split into "reservation" and "id" when a path lookup is attempted. No attempt to use "reservation_id" is made.
2. The TypeInformation (ClassTypeInformation instance) being passed in has a "reservation"->Optional.empty entry in the fields object. No equivalent exists in the actual entity.