chore: update Spring Boot 3.5.9, Hibernate 6.6.5#3413
chore: update Spring Boot 3.5.9, Hibernate 6.6.5#3413
Conversation
… 3.14.1 - Spring Boot: 3.4.9 → 3.5.9 - Hibernate ORM: 6.5.3.Final → 6.6.5.Final - Hypersistence Utils: 3.10.1 → 3.14.1 Breaking change fix: Renamed ImportFile.import to ImportFile.importData to avoid Java reserved keyword conflict with Hibernate 6.6's stricter compile-time annotation processor. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 📝 WalkthroughWalkthroughA comprehensive refactoring that renames the Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
Refactor entity migration to detach the legacy user before reassigning entities. This prevents Hibernate 6.6's stricter orphanRemoval from deleting entities that are being transferred to a new owner. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Clear UserAccount.preferences reference after removing the entity to avoid validation error during auto-flush - Synchronize bidirectional relationship in TestDataService when saving UserPreferences to ensure the UserAccount references the managed entity Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Add deleteAllByKeyIdIn and deleteAllByKeyProjectId to TaskKeyRepository to explicitly delete TaskKey entries before deleting Keys - Flush and clear the persistence context after deleting related entities (translations, metas, screenshots, task keys) to prevent Hibernate 6.6's stricter CHECK_ON_FLUSH from seeing stale relationships with orphanRemoval - Re-fetch keys after clearing context to ensure clean state before deletion Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Hibernate 6.6 introduced stricter validation during flush that checks all managed entities have consistent relationships. This caused TransientObjectException when deleting projects because: 1. Entity-based deletion (repository.deleteAll) marks entities as "removed" but other entities in the session still reference them 2. On flush, Hibernate 6.6 sees these stale references and throws Fixes: - ProjectHardDeletingService: Add flush/clear before and after batch job deletion, and use bulk JPQL DELETE for project and related entities (Automation, ContentDeliveryConfig, ContentStorage, WebhookConfig, etc.) - BatchJobService: Rewrite deleteAllByProjectId to use bulk JPQL queries with project.id filtering instead of loading entities into memory. This also handles the case of millions of batch jobs per project. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Spring Boot 3.5.x changed relaxed binding precedence for environment variables. Using uppercase SPRING_PROFILES_ACTIVE ensures proper profile activation regardless of Dockerfile settings. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Hibernate 6 is stricter about nullability in Spring Data projections. The repository query uses LEFT JOIN for translations, which returns null when a key has no base translation. The interface must declare the field as nullable to match the actual query results. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Summary
Breaking Change Fix
Renamed
ImportFile.import→ImportFile.importDatato avoid Java reserved keyword conflict with Hibernate 6.6's stricter annotation processor.Test plan
🤖 Generated with Claude Code
Summary by CodeRabbit
Documentation
Chores
✏️ Tip: You can customize this high-level summary in your review settings.