use modifications_order for the composites

[Mathieu-Deharbe]

PR Summary

• replaces the OrderColumn annotation used for the modifications contained inside a composite, with the modificationOrder ot ModificatoinEntity.
• removed removeOrphan because now modifications may be "orphan" when removed from composite and put into groups. They shoudn't be deleted in this case.
• few renaming and reorganisations along the way to make more readable what confused me (and remove some useless actions)

[coderabbitai]

🧹 Nitpick comments (1)

src/main/java/org/gridsuite/modification/server/repositories/NetworkModificationRepository.java (1)

668-680: Consider using flatMap for conciseness (optional).

The forEach loop building a list could be simplified, though the current approach is readable and maintains clear per-composite ordering.

♻️ Optional refactor using flatMap

 private List<ModificationInfos> getModificationsInfosInsideCompositesNonTransactional(`@NonNull` List<UUID> compositeUuids) {
-    List<ModificationInfos> entities = new ArrayList<>();
-    compositeUuids.forEach(uuid -> {
-        List<UUID> foundEntities = modificationRepository.findModificationIdsByCompositeModificationId(uuid);
-        List<ModificationInfos> orderedModifications = foundEntities
-                .stream()
-                .map(this::getModificationInfo)
-                .toList();
-        entities.addAll(orderedModifications);
-    }
-    );
-    return entities;
+    return compositeUuids.stream()
+            .flatMap(uuid -> modificationRepository.findModificationIdsByCompositeModificationId(uuid).stream())
+            .map(this::getModificationInfo)
+            .toList();
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/org/gridsuite/modification/server/repositories/NetworkModificationRepository.java`
around lines 668 - 680, Replace the manual forEach accumulation in
getModificationsInfosInsideCompositesNonTransactional with a single stream
pipeline using flatMap to keep code concise while preserving per-composite
ordering: stream compositeUuids, flatMap each uuid to
modificationRepository.findModificationIdsByCompositeModificationId(uuid).stream(),
map each id with this::getModificationInfo, and collect to a
List<ModificationInfos>; ensure you still return the collected list and keep
method signature unchanged.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In
`@src/main/java/org/gridsuite/modification/server/repositories/NetworkModificationRepository.java`:
- Around line 668-680: Replace the manual forEach accumulation in
getModificationsInfosInsideCompositesNonTransactional with a single stream
pipeline using flatMap to keep code concise while preserving per-composite
ordering: stream compositeUuids, flatMap each uuid to
modificationRepository.findModificationIdsByCompositeModificationId(uuid).stream(),
map each id with this::getModificationInfo, and collect to a
List<ModificationInfos>; ensure you still return the collected list and keep
method signature unchanged.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 1c4d95d0-eb3c-4711-b7c2-178d4c1ee334

📥 Commits

Reviewing files that changed from the base of the PR and between 4437ed0 and ddf31ce.

📒 Files selected for processing (1)

• src/main/java/org/gridsuite/modification/server/repositories/NetworkModificationRepository.java

[Meklo]

LGTM, just minor remark

[Meklo]

Could oprhanRemoval be kept as a security ?

[Mathieu-Deharbe]

Since I do everything with entity lists without copying it like it was done before, JPA considers an entity to be orphan when I remove it from the list of movedEntities and automatically delete it. (while I just moved it to rootNode/group, but technically it is no longer referenced by any composite)

I could probably keep Orphan Removal by making a copy of the entity table, but it would lose a bit in performance and it would be less "JPA entity pure".

I’m not sure what is best and if there is another way.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
95.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Meklo]

I've noticed you've removed movedEntities.forEach(movedEntity -> movedEntity.setGroup(group)); but kept movedMods.forEach(entity -> entity.setGroup(null)); above line 979 is it deliberated ?

[Mathieu-Deharbe]

Well seen.
I did this because movedEntities.forEach(movedEntity -> movedEntity.setGroup(group)); is already done in the following group.setModifications(rootMods); so it shouldn't be needed.

On the other hand when the group is set to null, we have to do it manually.