Document default `NamingStrategy` and explain configuration options

[RobertHeim]

Hey, thanks for the work on the project, it works pretty well and we enjoy our work with it!

I am using spring-boot 2.5.1 with spring-boot-starter-data-r2dbc and io.r2dbc:r2dbc-postgresql.
I thought it might be related to #483 and I am not sure if it is the right repository to post the issue, so feel free to move it to spring data relational/jdbc if it is more appropriate.

I just figured out that this query:

interface TaskReviewRepository : CoroutineCrudRepository<TaskReview, Long> {
  @Query(
    """
    SELECT task_id, AVG(rating) as avgRating, COUNT(*) as reviewsCount
    FROM task_review
    WHERE task_id IN (:taskIds)
    GROUP BY task_id
  """
  )
  fun ratingSummaryWhereTaskIdIn(taskIds: Set<Long>): Flow<TaskReviewService.RatingSummaryWithTaskId>
}

and this data class

data class RatingSummaryWithTaskId(
  val taskId: Long,
  val avgRating: Double?,
  val reviewsCount: Long,
)

fails with

2021-06-30 09:22:33.240 DEBUG 7529 --- [     parallel-3] io.r2dbc.postgresql.PARAM                : Bind parameter [0] to: 1
2021-06-30 09:22:33.246 DEBUG 7529 --- [     parallel-3] io.r2dbc.postgresql.QUERY                : Executing query: 
    SELECT task_id, AVG(rating) as avgRating, COUNT(*) as reviewsCount
    FROM task_review
    WHERE task_id IN ($1)
    GROUP BY task_id
// ...
org.springframework.data.mapping.model.MappingInstantiationException: Failed to instantiate com.example.tasks.TaskReviewService$RatingSummaryWithTaskId using constructor fun <init>(kotlin.Long, kotlin.Double?, kotlin.Long): com.example.tasks.TaskReviewService.RatingSummaryWithTaskId with arguments 1,null,null
    at org.springframework.data.mapping.model.ClassGeneratingEntityInstantiator$EntityInstantiatorAdapter.createInstance(ClassGeneratingEntityInstantiator.java:246) ~[spring-data-commons-2.5.1.jar:2.5.1]
    Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException: 
// ...
Caused by: java.lang.IllegalArgumentException: Parameter reviewsCount must not be null!

while this query (snake case)

SELECT task_id, AVG(rating) as avg_rating, COUNT(*) as reviews_count
FROM task_review
WHERE task_id IN (:taskIds)
GROUP BY task_id

works fine.

I suggest supporting camelCase in the alias for selected columns or at least to provide an error message that camelCase is not supported, because it took me several hours to figure this out.

[mp911de]

Thanks for report and sorry to hear about your inconvenience. Spring Data JDBC and R2DBC use snake case as the default NamingStrategy if @Column is not provided. I realized that neither the JDBC nor the R2DBC documentation provides a hint towards the default naming strategy.

You can generally configure a different one when constructing R2dbcMappingContext.

[mp911de]

Paging @schauder

[RobertHeim]

Thanks for the feedback.

Actually, I expected the mapping would prefer the alias of the query and would use the index in the select statement to create the object. But that probably is error prone when having * selects. I understand that sticking to a specific naming strategy is more predictable.

A hint in the docs would be great and if possible a warning when aliases do not match the applied naming strategy would be very helpful.

[schauder]

I'm against trying different strategies. That is just asking for trouble.

Providing a better error message would be nice, but the problem is that the exception doesn't come from Spring Data but from the domain object, so we have no reliable way to add information to that.

Using indexes is not an option I think. I'd consider that a step in the wrong direction. It is really brittle and would leave even less information what is going on.

What we could do is log information when we fail to find a column X but find a column Y where

• X != Y
• Y isn't used otherwise
• X~=Y (Levenshtein distance < 3 or something maybe)

If we do that only once per query, it could be logged as a warning without being overly annoying.

[schauder]

We decided against heuristic warnings but I tried to improve the documentation with #617

[RobertHeim]

Thank you for following up so quickly and the improved documentation!