Skip to content

Detect missing MongoDB value representations - #1098

Open
Kyran121 wants to merge 3 commits into
openrewrite:mainfrom
Kyran121:detect-mongodb-value-representations
Open

Detect missing MongoDB value representations#1098
Kyran121 wants to merge 3 commits into
openrewrite:mainfrom
Kyran121:detect-mongodb-value-representations

Conversation

@Kyran121

@Kyran121 Kyran121 commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

What changed

  • Add FindMissingMongoValueRepresentation, a project-scoped diagnostic recipe for Spring Data MongoDB 5 migrations.
  • Detect explicitly MongoDB-mapped UUID, BigDecimal, and non-ID BigInteger fields that require an explicit value representation, including nested collection and map-value types, and report every affected field in the MongoValueRepresentationFields data table.
  • Recognise valid representation configuration in Java, .properties, and YAML, including relaxed value spellings and property placeholders. Test-source configuration does not suppress main-source diagnostics, and invalid profile overrides are still reported when a valid default exists.
  • When a representation is missing, add the relevant Spring property with the bindable value UNSPECIFIED and an explanatory comment to the preferred main application*.properties/.yml/.yaml file. Generate src/main/resources/application.properties when the project has no suitable configuration file.
  • When an existing Java, properties, or YAML configuration is blank, malformed, unsupported, null, or explicitly UNSPECIFIED, add a persisted comment directly to the offending source rather than relying on a transient search marker.
  • Avoid silently choosing a storage representation: users must replace UNSPECIFIED with the value matching their existing BSON data.
  • Keep generated suggestions, diagnostic comments, and data-table rows idempotent across recipe cycles and separate invocations.
  • Compose the diagnostic into UpgradeSpringDataMongoDb_5_0 and register the recipe metadata.

Validation

  • Covered by focused tests for configured and unconfigured projects, Java/properties/YAML configuration, profile overrides, generated baseline configuration, Mongo mapping boundaries, nested values, invalid configuration, composite execution, and idempotency.
  • Verified through the unit test suite and against representative Spring projects using the actual Gradle plugin.

Closes #1083.
Part of #1081.

@github-project-automation github-project-automation Bot moved this to In Progress in OpenRewrite Jul 24, 2026
@Kyran121
Kyran121 force-pushed the detect-mongodb-value-representations branch 7 times, most recently from 1a1cda7 to 8b67552 Compare July 25, 2026 16:57
@Kyran121
Kyran121 force-pushed the detect-mongodb-value-representations branch from 55b2bc6 to 37c8625 Compare August 2, 2026 00:10
Kyran121 added a commit to Kyran121/rewrite-spring that referenced this pull request Aug 2, 2026
UpgradeSpringDataMongoDb_5_0RepresentationTest still asserted the
removed class-level fallback marker, which is what broke CI on PR
openrewrite#1098; updated to expect the baseline-file generation it was replaced
by.

Manual end-to-end testing against a real Gradle rewriteRun (not just
RewriteTest) surfaced three further correctness issues invisible to
the unit suite:

- SearchResult markers on invalid property/YAML/Java entries were
  printed as literal `~~(...)~~>` text in real (non-dry-run) output,
  contrary to SearchResult's own contract. For properties this was
  destructive: everything before `=` becomes the key, silently
  deleting the flagged property. Now relies solely on the real,
  persisted Comments.of(...) comment already used alongside it.
- Recipe.causesAnotherCycle() defaults to false, so a real invocation
  stopped right after generating a baseline configuration file, before
  the following cycle that populates it ever ran, leaving a 0-byte
  file. Now overridden to true.
- Suggested properties were created with placeholder text
  ("<representation>") that could crash Spring Boot's config binding
  on startup if never followed up on. Both formats now use a real,
  safely-bindable UNSPECIFIED value instead — the same state a user
  explicitly writing UNSPECIFIED would produce, so it's detected and
  commented via the existing, already-tested invalid-value path
  instead of a separate "missing" one.

Simplified as a result:
- YAML suggestions merge into the document as proper nested mappings
  via the existing AddSpringProperty (which already dispatches
  per-format internally) instead of a hand-rolled MergeYaml call
  duplicating that same logic.
- AddSpringProperty's comment parameter attaches the diagnostic
  comment at creation time instead of deferring it to a follow-up
  cycle, cutting a cycle off both the existing-config-file and
  baseline-generation cases.
- Removed now-redundant comments and duplicated deferred-finalization
  logic (extracted into a single finalizeUnless helper) in favor of
  names and structure that carry the same intent.

Verified against real dummy Spring projects via the actual Gradle
plugin, not just the unit test harness.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@Kyran121
Kyran121 force-pushed the detect-mongodb-value-representations branch from 9b23f96 to 47df833 Compare August 2, 2026 23:43
@Kyran121
Kyran121 force-pushed the detect-mongodb-value-representations branch from 47df833 to f179acd Compare August 3, 2026 17:42
@Kyran121
Kyran121 marked this pull request as ready for review August 3, 2026 19:26
@Kyran121

Kyran121 commented Aug 3, 2026

Copy link
Copy Markdown
Contributor Author

@timtebeek - ready to review

@Kyran121 Kyran121 closed this Aug 17, 2026
@Kyran121 Kyran121 reopened this Aug 17, 2026
@github-project-automation github-project-automation Bot moved this from In Progress to Done in OpenRewrite Aug 17, 2026
@github-project-automation github-project-automation Bot moved this from Done to In Progress in OpenRewrite Aug 17, 2026
Adds FindMissingMongoValueRepresentation, a project-scoped diagnostic
recipe that finds explicitly MongoDB-mapped UUID, BigDecimal, and
non-ID BigInteger fields requiring an explicit value representation
on Spring Data MongoDB 5, reporting them via the
MongoValueRepresentationFields data table. It's composed into
UpgradeSpringDataMongoDb_5_0.

- Suggests a real, safely-bindable UNSPECIFIED property (merged into
  the document as proper nested YAML mappings, or a plain properties
  entry) with an explanatory comment, in the project's main
  application*.properties/.yml/.yaml, or a generated baseline file
  when none exists.
- Flags blank, malformed, unsupported, or UNSPECIFIED values with a
  real, persisted comment directly on the offending Java, properties,
  or YAML source, rather than a transient marker.
- Recognises valid configuration (including relaxed spellings and
  property placeholders) across Java, properties, and YAML, and flags
  invalid profile overrides even when a valid default exists elsewhere.
- Idempotent both within a single run and across separate invocations.

Verified via the unit test suite and against real dummy Spring
projects through the actual Gradle plugin, not just the test harness.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@Kyran121
Kyran121 force-pushed the detect-mongodb-value-representations branch from f179acd to 7e7eeb5 Compare August 17, 2026 21:14
Kyran121 and others added 2 commits August 17, 2026 22:21
…representations

# Conflicts:
#	src/main/resources/META-INF/rewrite/recipes.csv
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

[Spring Data MongoDB 5.0] Detect missing explicit value representation configuration

2 participants