Check https://github.com/spring-projects/spring-data-elasticsearch/issues/2110 for details

Comment From: mhalbritter

As @sothawo said, you're right, and this is a breaking change. We can change this in the next release. Adding it to the documentation should be easier, though. I've created ticket https://github.com/spring-projects/spring-boot/issues/30103 for this.

Comment From: mhalbritter

We should remove the set-calls in the auto-configuration and rely on Spring Data's defaults.

Comment From: wilkinsona

We can remove this set call as a task in 2.5.x:

https://github.com/spring-projects/spring-boot/blob/44f71a46aa01c90ff0910a27627107e13a282841/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/data/elasticsearch/ElasticsearchDataConfiguration.java#L111

The default is already RefreshPolicy.IMMEDIATE so it is redundant. Removing it will allow us to automatically pick up any future change in Spring Data Elasticsearch.

This set call is a bit trickier:

https://github.com/spring-projects/spring-boot/blob/44f71a46aa01c90ff0910a27627107e13a282841/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/data/elasticsearch/ElasticsearchDataConfiguration.java#L110

Here we have a different default to Spring Data Elasticsearch. I think we should align but we need to decide when to do that.

We may also want to offer configuration properties for the template’s settings to make the defaults easier to change without defining a new bean.

Comment From: sothawo

Another info, I still have to see how this default setting and a change affects this: When using the operations, i.e. the "low level" operation the default should be to not set anything and so use Elasticsearch 's default (which is not immediate). A user that saves an entity and directly needs it to be accessible would then have to either set the refresh policy or do an explicit refresh() call before doing a search()

But when using the higher level repository functions the user expects the data to be available after a save. There used to be an explicit call to refresh after writing operations, I think I changed that to do the writing operations with immediate refresh when called from the repository implementation.

That's nothing that is of your concern, but I think I need to add some detailed information to our docs in Spring Data Elasticsearch .

Comment From: ToffeeLu

I think I need to add some detailed information to our docs in Spring Data Elasticsearch

Really appreciate! That's exactly what I want! It doesn't matter what's the default value is, because there always some tradeoff, but user need to know.

Comment From: snicoll

@wilkinsona I am trying to see if I can help but I don't know why it was flagged for team attention.

Comment From: wilkinsona

Thanks, @snicoll. I flagged it for a couple of reasons (and did a poor job of making it obvious what they were):

  1. What should we do about aligning the default value of the template's indicesOptions property with SD Elasticsearch?
  2. Should we add some properties for tuning the template's configuration? Doing so might make 1 easier as it would provide a straightforward way for users to restore the current behaviour

Comment From: mhalbritter

  1. I would let handle Spring Data the defaults. As this is a (minor) breaking change, I would do it in 2.7.x. Adding a note in Spring Boot documentation which references the Spring Data documentation on that part won't hurt
  2. Good idea, i would add the config properties. Then we can put a hint to them into the release notes to easily restore current behaviour

Comment From: wilkinsona

I've opened #30375 to remove the redundant setting of the refresh policy, #30378 to align the default of indices options, and #30379 to add some configuration properties. I'm going to close this issue as it has been superseded by these three separate issues.