Transition to `org.springframework.data.core.div` in Kotlin DSL

[Patouche]

Hi Spring Data team !

Following my analysis in spring-projects/spring-data-mongodb#5216 on Kotlin DSL behaviors.

Currently, when using the Kotlin DSL for mongodb, we can use the div operator to query nested properties:

import org.springframework.data.mapping.div

mongoOperations.find<Book>(
  Query(Book::author / Author::name regex "^H")          
)
// { "author.name": /^H/ }

However, the div operator is now deprecated, with a recommendation to use the one from org.springframework.data.core.div. At the moment, if we replace the div operator with the new one, it generates the following query: { "name": /^H/ }

import org.springframework.data.core.div

mongoOperations.find<Book>(
  Query(Book::author / Author::name regex "^H")          
)
// { "name": /^H/ }

This behavior is incorrect, as it drops the parent path and may lead to invalid queries.

IMHO, it would be a good idea to extend the org.springframework.data.core.asString(property: KProperty<*>) function to support the previous org.springframework.data.mapping.KPropertyPath and org.springframework.data.mapping.KIterablePropertyPath types within the when statement. (see asString )

This would ensure that calls made through org.springframework.data.core.toDotPath() correctly handle both versions of the div operator.

Updating spring-data-mongodb to rely on org.springframework.data.core.toDotPath() would allow users to use either org.springframework.data.core.div or org.springframework.data.mapping.div while producing identical queries.

I think this would provide a smoother migration path for users.

Any thoughts ?

Regards,
Patouche

[mp911de]

Thanks for reaching out. I fear introducing TypedPropertyPath and revising the Kotlin extension resulted in loss of functionality on the replacement functionality, therefore I consider this a regression. With your analysis already pointing towards a good direction. The actual bug is that the two asString functions each only recognize the path types from their own package, and fall through to else -> property.name (the leaf only, parent dropped) for the other's types.

For a fix, the two path types that core.asString would need to recognize currently have fairly restrictive visibility in
org.springframework.data.mapping/KPropertyPath.kt:

• KPropertyPath is file-private, so it is not referenceable from the core package as things stand.
• KIterablePropertyPath is internal and therefore module-visible, so core can already reach it within the same module.

To make this work we would need to relax the visibility a little, for example by turning mapping.KPropertyPath into an internal class and exposing its parent and child, and then add the corresponding when branches in core.asString.

Let me know whether you have different idea in mind to approach this problem so we can find the best balance between visibility constraints and limiting the blast radius.