import JDL subgenerator overwrites changelogdate even for not unaltered tables while regenerating entity

[pramika]

Overview of the issue

import JDL subgenerator updates changelogdate in .json files for all the entities (while regenerating entity) instead of only the modified entity. Because of which conflict occurs and overwrite question is asked for all the .json and .java files. This also impact the audit module where again all the .json, .java and .xml file are overwritten again for all the entities.

The expected behaviour is only the files for the modified or newly added entities to be overwritten.

Though we use a new jh file for regeneration removing the unaltered tables, the regeneration fails due to the dependency in these tables. As a result we have to add all the dependency tables. Since we have lot of custom logics written in these generated files the code maintenance is getting complicated.

Motivation for or Use Case

Maintenance is becoming complex as when the number of table increases, the number of overwrite questions are also increasing. Currently I have around 10 tables in my development. If I change one table and regenerate entity using import JDL subgenerator around 60 overwrite questions are asked even for the unaltered tables. This includes the audit overwrite question as well. ChangeLogDate field in the .json file is getting updated irrespective of the new or modified tables due to which all the .json and .java files are updated

JHipster Version(s)

3.4.0

JHipster configuration, a .yo-rc.json file generated in the root folder

{ "generator-jhipster": { "jhipsterVersion": "3.4.0", "baseName": "TEGTracker_v4", "packageName": "com.tcs.tegtracker", "packageFolder": "com/tcs/tegtracker", "serverPort": "8080", "authenticationType": "session", "hibernateCache": "no", "clusteredHttpSession": "no", "websocket": "no", "databaseType": "sql", "devDatabaseType": "mysql", "prodDatabaseType": "mysql", "searchEngine": "no", "buildTool": "maven", "enableSocialSignIn": false, "rememberMeKey": "8af9a4f2db413e9d3629564b71520896c96e6956", "useSass": true, "applicationType": "monolith", "testFrameworks": [ "gatling" ], "jhiPrefix": "jhi", "enableTranslation": true, "nativeLanguage": "en", "languages": [ "en" ] }, "generator-jhipster-entity-audit": { "auditFramework": "custom" } }

[MathieuAA]

Hi, I will fix it as soon as the #toJSON service is added to this project (currently in JUML).

[pramika]

Great. Thanks a lot for the update.

[pramika]

Any updates on this bug?

[MathieuAA]

No. The entity creator has to move here first. And the current branch where the core objects are being implemented has to be merged first. Work on the issue is alread documented and should begin/end this week-end.

Le 10 juin 2016 12:16:23 GMT+02:00, pramika notifications@github.com a écrit :

Any updates on this bug?

---

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/jhipster/jhipster-domain-language/issues/26#issuecomment-225146421

Mathieu ABOU-AICHI

[MathieuAA]

@deepu105 I'm almost wondering if this should not be done by the client instead of a piece of code here... first because it's a really easy thing to do (I can even make the entity comparator available if need be), and because this project won't be the one calling yo jhipster:entity <MyEntity>.json. What do you think? See eb23bc1.

[deepu105]

The entity sub gen doesn't overwrite the changelogDate if its already present so this is something that should be done while writing the json files itself. since the json data is provided by jhipster-core it might be best to filter out unmodified entities here as it was done in JH UML as well. So I woulnt mind this step being done directly here when the force attribute is not passed else it can be done in the sub generator as well.

BTW since these are not blocking issues can we take care of these later and make a release first?

[MathieuAA]

I didn't understand the problem! You're right, I may be able to do it tonight and make a release right after.

[MathieuAA]

Everything has been implemented in d9785e9. Only the call to yo jhipster:entity is not performed by this project.