You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Incremental changelog won't count up timestamp or won't use the current timestamp but always the creation timestamp leading to incorrectly overwritten changelog files
#25285
Closed
1 task done
OmarHawk opened this issue
Feb 21, 2024
· 0 comments
· Fixed by #25311
We do have an issue with incremental changelog generation, since v8. We have an existing application with a defined jdl, modify the jdl and let the jhipster jdl jdl.jdl command run.
The problem is, it will always use the creationTimeStamp for file names as prefix for the changelog files and for changelog ids, therefore, two consecutive updates to the very same entity will override each other and you need to manually do something about it, or your liquibase changelog will break. In previous versions (7.9.3), the current timestamp was used instead, so everytime the jdl command was run, a completely new set of files was produced.
Motivation for or Use Case
Shouldn't have to manually fix something over the application lifecycle.
Reproduce the error
Create a basic application.
Generate an initial schema using jhipster jdl jdl.jdl --incremental-changelog command for incremental changelogs
Change an entity in the jdl (remove a field) and let the jhipster jdl jdl.jdl command run again
Change the same entity again (add a field) and let the jhipster jdl jdl.jdl command run again and see that JHipster tries to override the already existing (and possibly already applied to database) file
You can see the last step in the following screenshots.
Here, the last step is visible, and JHipster tried to override the already existing update file:
This is the file content before JHipster does so:
And this is after JHipster has done so:
Related issues
Nothing found
Suggest a Fix
JHipster Version(s)
8.1.0
JHipster configuration, a .yo-rc.json file generated in the root folder
Overview of the issue
We do have an issue with incremental changelog generation, since v8. We have an existing application with a defined jdl, modify the jdl and let the jhipster jdl jdl.jdl command run.
The problem is, it will always use the creationTimeStamp for file names as prefix for the changelog files and for changelog ids, therefore, two consecutive updates to the very same entity will override each other and you need to manually do something about it, or your liquibase changelog will break. In previous versions (7.9.3), the current timestamp was used instead, so everytime the jdl command was run, a completely new set of files was produced.
Motivation for or Use Case
Shouldn't have to manually fix something over the application lifecycle.
Reproduce the error
jhipster jdl jdl.jdl --incremental-changelog
command for incremental changelogsjhipster jdl jdl.jdl
command run againjhipster jdl jdl.jdl
command run again and see that JHipster tries to override the already existing (and possibly already applied to database) fileYou can see the last step in the following screenshots.
Here, the last step is visible, and JHipster tried to override the already existing update file:
This is the file content before JHipster does so:
And this is after JHipster has done so:
Related issues
Nothing found
Suggest a Fix
JHipster Version(s)
8.1.0
JHipster configuration, a
.yo-rc.json
file generated in the root folder.yo-rc.json file
Environment and Tools
openjdk version "17.0.7" 2023-04-18 LTS
OpenJDK Runtime Environment (Red_Hat-17.0.7.0+7-1) (build 17.0.7+7-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-17.0.7.0+7-1) (build 17.0.7+7-LTS, mixed mode, sharing)
git version 2.43.0.windows.1
node: v18.19.0
npm: 10.2.3
Docker version 24.0.7-rd, build 72ffacf
JDL for the Entity configuration(s)
entityName.json
files generated in the.jhipster
directoryJDL entity definitions
Entity configuration(s)
entityName.json
files generated in the.jhipster
directoryBrowsers and Operating System
The text was updated successfully, but these errors were encountered: