Refine representation format defaulting for `UUID`, `BigDecimal`, and `BigInteger`

[mp911de]

With the changes #4920/#4957 and #3932/#5034, we switched default representations for UUID, BigDecimal, and BigInteger values. Switching a default is a subtle change that isn't immediately visible (in contrast to a clearly behavioral or breaking API change) but can remain invisible until a late deployment or operational stage.

A way out would be removing defaulting and requiring a choice expressed by application configuration. It would help to fail early if e.g. the domain model uses UUID's or BigDecimals in implicit field target mode and an associated configuration property isn't set to indicate we require a user choice.

Another alternative could be leaving defaults as-is but issuing warn logging if the default value is implicitly (i.e. not explicitly configured) used.

[HyunSangHan]

@mp911de
Hi! It's very interesting topic :)
I think both of the options you mentioned make sense.

What do you think about approaching this in two phases?

1. For now: keep the current defaults but log a clear warning whenever they’re used implicitly.
2. In the next major release: remove the defaults entirely so that users must configure the representation explicitly.

That way we give teams time to adjust without breaking their current setups, while still moving toward the safer "explicit config" model.
If that sounds reasonable, I’d be happy to work on a PR for the warning-logging part first.

[mp911de]

We cannot know whether these ared used implicitly, only Boot can know, but I am not sure this is ideal. For some users, a default might be just fine.

That way we give teams time to adjust without breaking their current setups

Upgrading to a new major comes with some work to properly upgrade. Setting two properties according to your current state is rather a small change.

In any case, thanks for your thoughts.

[HyunSangHan]

Oh, you’re right. There are clear limitations on the Spring Data MongoDB side. 🤔

I believe your original approach makes more sense: remove the defaults and require explicit configuration.
This would be a clean breaking change that forces users to be explicit about their data representation choices.

In that case, can I go ahead and prepare a PR for removing the defaults, so we can review it together and continue the discussion?

[mp911de]

This could be actually approached by leveraging MappingContextEvent:

@Bean
ApplicationListener<MappingContextEvent<? extends MongoPersistentEntity<?>, ?>> validatingListener() {

	MongoMappingContext context = null; // optional to filter only events from a specific context

	return new ApplicationListener<MappingContextEvent<? extends MongoPersistentEntity<?>, ?>>() {
		@Override
		public void onApplicationEvent(MappingContextEvent<? extends MongoPersistentEntity<?>, ?> event) {

			if (!context.equals(event.getSource())) {
				return;
			}

			for (MongoPersistentProperty property : event.getPersistentEntity()) {

				Class<?> fieldType = property.getFieldType();
				if (fieldType == UUID.class) {
					// verification and throw exception if not configured properly
				}

				if (fieldType == BigDecimal.class || fieldType == BigInteger.class) {
					// verification and throw exception if not configured properly
				}
			}
		}
	};
}

Initially, a MappingContext doesn't know about all persistent entities, only those, that are annotated with @Document. Entities aren't required to be annotated and those could be used in repositories or application code directly. Using a listener would catch them all.