Proper procedure for modifying JHipster Entities using JDL - jhipster

I am trying out JHipster (version 6.4.1) using a Monolith and disk-based H2 database. I have created some entities in JDL and have the basic CRUD webpages working. Now that I feel comfortable with the process, I want to add fields and rename others. I figured I could simply update the JDL, re-import the JDL, start the application, and see the result of my changes. What I see is ValidationFailedException from Liquibase and the application throwing HTTP 500 errors due to database problems.
I have looked all over for guidance on the proper process for handling this seemingly common development scenario. Most of the places I have looked for guidance (such as https://www.jhipster.tech/creating-an-entity) discuss importing JDL as a one-time-only operation and do not discuss how to incrementally change and import the JDL.
I have tried a number of suggestions as seen on SO, such as not overwriting the changelogs, doing a liquibase:diff, and adding that to master.xml. This still causes the ValidationFailedException. In the master.xml I see the comment <!-- jhipster-needle-liquibase-add-changelog - JHipster will add liquibase changelogs here --> which leads me to believe that JHipster should be doing the heavy lifting, but I am just missing a step.
I am by no means a JHipster nor a Liquibase expert, but I want to learn. How I can perform simple entity updates without a huge hassle?
[Update with more detail]
After re-importing the updated JDL, I have managed to get rid of the DB Validation Errors by blowing away the database with rm -rf target/h2db/db.
I'm happy with my changes and feel like a commit is in order. What I see is
master.xml is unchanged
the changelog from the first JDL import has been modified to include the updates I made
If I understand how liquibase works, I would have expected
None of the existing changelogs would be touched
A brand new changelog file would be created that contained just the JDL changes I made this round
master.xml to have changed only in that it would contain an additional changelog entry, pointing to the file created in item 2
Am I misinterpreting how Liquibase represents evolution of the DB schema?

It appears that the page you referenced does have some instructions for updating entities. Farther down the page I saw this:
Updating an existing entity
The entity configuration is saved in a
specific .json file, in the .jhipster directory. So if you run the
sub-generator again, using an existing entity name, you can update or
regenerate the entity.
When you run the entity sub-generator for an existing entity, you will
be asked a question ‘Do you want to update the entity? This will
replace the existing files for this entity, all your custom code will
be overwritten’ with following options:
Yes, re generate the entity - This will just regenerate your entity.
Tip: This can be forced by passing a --regenerate flag when running
the sub-generator
Yes, add more fields and relationships - This will
give you questions to add more fields and relationships
Yes, remove fields and relationships - This will give you questions to remove
existing fields and relationships from the entity
No, exit - This will exit the sub-generator without changing anything
You might want to
update your entity for the following reasons:
You want to add/remove fields and relationships to an existing entity
You want to reset your entity code to its original state
You have updated JHipster, and would like to have your entity generated with
the new templates
You have modified the .json configuration file (the
format is quite close to the questions asked by the generator, so it’s
not very complicated), so you can have a new version of your entity
You have copy/pasted the .json file, and want a new entity that is
very close to the copied entity

Related

How to remove Required field from an entity in Jhipster

I am new to Jhipster and I want to remove required field from column without changing anything else like
table name in h2 db or the names of the columns in that table. I tried to remove #NotNull annotation from entity name and set field in database to null but when i run integration test using
mvnw verify i get this error
EmployeeResourceIT.checkCompanyIsRequired:124 Status expected:<400> but was:<201>
Thank you in advance!
You must modify the EmployeeResourceIT test also so that it does not verify company requirement anymore.
It would be simpler to modify your JDL file to change the constraint on this field and import it.
And if you did not use JDL, you should learn it, it's more powerful than answering questions (see https://www.jhipster.tech/jdl/getting-started)
You can create your JDL file from your existing project using jhipster export-jdl

Removing an Entity completely from Jhipster built Application

I have a requirement to accompish, which is to delete an entity completely, which has been created using jhipster.
If I use the command "jhipster entity entityName", it gives option to delete fields and relationships only but not complete removal of entity. While doing some research, I came across this link [https://github.com/jhipster/generator-jhipster/pull/4369][1]. But there seems to be no solution to it.
Also if I'm using the above command to remove the fields and relationships with the help of the existing entityName.json file in .jhipster folder to avoid the prompts on cmd, I need to keep the fields and relationships keys in that json file as null or [], right?
Looking for some help on this.Thanks.

Can the "--skip-client" entity parameter be applied to only some entities?

Using Jhipster 7.0.1, I'd like to generate entities where only a select few have their client-side-code generated. Generation without the client-side works as expected at first, but any subsequent entities with a frontend will force all entities to have a their client-side code generated.
To replicate the issue:
Generate an entity without a frontend. This correctly creates only server-sided code. jhipster entity Foo --skip-client
Generate an entity normally. jhipster entity Bar
*For the test, entities were not created with any relationships.
After generation, both Foo, and Bar will have client-side code generated. The log entry seems to highlight the issue:
Found the .jhipster\Foo.json configuration file, entity can be automatically generated!
When client-side only entities are created, its seems that there's no configuration saved in the .jhipster\Foo.json files to accommodate the --skip-client parameter. I could simply delete the json files of server-side only entities and thier corresponding entries in .yo-rc.json, but I'm concerned I'll run into issues upgrading Jhipster if they've been removed. Is there a better way I can accomplish this?
Edit:
I may have found a solution. Adding both "skipClient" & "skipServer" entries to every .jhipster/*.json file seems to resolve the issue.
.jhipster\Foo.json
{
"name": "Foo",
"skipClient": true,
"skipServer": false
}
I believe this may be a bug where Jhipster is not adding the configuration on its own.
Adding both "skipClient" & "skipServer" entries manually to every .jhipster/*.json file seems to resolve the issue.
.jhipster\Foo.json
{
"name": "Foo",
"skipClient": true,
"skipServer": false
}
I believe this may be a bug where Jhipster is not adding the configuration on its own.
I opened a ticket here: https://github.com/jhipster/generator-jhipster/issues/15366

Unmanaged installation and Entities data

I have unmanaged solution installed in un online prod environnement and I want to install a new version of this solution in the same environnement, my question is that if I do that, what will happen to my data entities as I don't want to lose my data from the environnement?
Thanks in advance,
The data in the base tables will be not be altered when importing a new solution.
It will be the entity definition.
If a new attribute has been created for an entity which is set to Business Required then a null value will be held until a user opens the form which will require that value to be supplied before the record can be updated.
+1 to Stefan's answer. I will also add that unmanaged solutions will never delete any data. It is always additive, so if you remove an attribute from an entity in your solution in dev, it will not be removed when you import it into another environment. You'll need to manually track these removals and remove them post solution deployment.

What is the best way to add tables to Entity Framework 6 Code First to Existing Database?

I'm developing an ASP.NET MVC 4.5 project using EF 6 Code First to an Existing Database. I would like to create some new tables with foreign key relationships to one of the tables in the dbcontext I've created. I've altered and added columns in that original table, creating several migrations. There is real data in that table.
I would prefer to create the new tables in the database, but don't see how EF would generate a model for me. I can code the model myself, but don't see any documentation about how I would add it to the context class generated by EF. And then the migrations would be out of whack.
So I'm thinking that the best thing to do would be to delete all the migrations, delete the context class and drop the migrations table. Then I could start from scratch with an initial migration. Am I missing some gotcha? Is there a better way?
FWIW to others facing this dilemma, I figured it out. First I got rid of all the migrations, following the 100+ up-voted answer here: Reset Entity-Framework Migrations
Second, I created new the tables and constraints I needed in the database.
Third, I created a new entity in my solution and generated model classes from the database. I changed calls from the old entity to the new entity.The generator overwrote the model for the original table, but since I have all the annotations in version control, it is trivial to paste them in.
If I need to, I can enable migrations again.
Hope this helps.

Resources