When I need to update an entity in jhipster just run jhipster entity MyEntity and apply new changes as desired to both: the entity and the associated changelog. So far so good. But what if I want the inverse result: defining the new fields/relations in the entity class and propagate those changes through the changelog and the frontend entity?
In this case, for instance:
#Column(name = "name")
#NotNull
#Pattern(regexp = "[a-zA-Z0-9]")
private String name;
According to what I have read, If I already have the name field but I want to add the above validations I have to add them into the proper liquibase changelog first and then in my java entity? Is that the only way?
It would be great to use this workflow, however, by my understanding it is not possible.
A possible solution would be to first regenerate the entity using jhipster cli or any other jhipster method. Once this step is completed, you could edit the entity in Java, adding complex validations or even refining the entity's relationship.
After any entity modification you must update Liquibase's changelog. You could do it manually or you could run ./gradlew liquibaseDiffChangeLog to generate a changelog containing all changes applied over the database. Don't forget to apply the generated changelog to the main changelog (src/main/resources/liquibase/master.xml).
Cheers!
Related
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
A freshly generated JHipster application contains already a basic model (e.g. with an User entity), lets call it m0.
I extended m0 by defining a model m1 with the JHipster Domain Language (JDL) and generating the entities.
For the authorization layer m1 had to reference the User in m0. I was able to achieve that by defining the User entity in the m1.jdl file like this:
entity User{}
The already existing User entity was not regenerated, only referenced from m1 - great!
Since m1 has to be extended with new entities regularly, it would be a dream to use the same pattern for m2, m3 referencing an entity in m1. But when I define AnM1Entity in m2.jdl like this:
entity AnM1Entity{}
Unfortunately AnM1Entity{} is regenerated and all attributes defined in m1.jdl for AnM1Entity are lost.
Why is User not regnerated and AnM1Entity is regenerated? Is there a way to skip the generation of AnM1Entity?
Or is there another way to extend JHipster application models in a convenient way?
thanks
User is never generated because it's not a JHipster entity, same for Authorities and all other predefined classes that are mapped to tables from initial database schema.
JDL does not support what you want.
If your goal is to preserve your manual changes from being overwritten by re-generation, you should have a look at what the community calls side-by-side approach:
JHipster conf 2019: https://www.youtube.com/watch?v=Gg5CYoBdpVo
JHipster conf 2018: https://www.youtube.com/watch?v=9WVpwIUEty0
Alternatively, you can rely on git by always generating on a branch and merging on master with git merging strategy options.
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
I use jhipster and I would like to modify the User entity and add fields and relationships.
I use jhipster entity user and this command is not good.
How can I do it?
User is not a JHipster entity, the generator does not manage it. You must edit the code manually or add a related entity where you put additional fields, see doc: https://www.jhipster.tech/tips/022_tip_registering_user_with_additional_information.html
If you encounter a problem where you need to alter the User entity, Its recommend not doing that. Modifying this default entity might break your app depending on the nature of the changes.
Instead, there are other available solutions like:
creating an entity composed of the User entity
extending the User entity
Using composition
by using OneToOne relation like this
entity ApplicationUser {
additionalField Integer min(42) max(42)
}
relationship OneToOne {
ApplicationUser{internalUser} to User
}
Or
Using inheritance
This solution does the same thing as the previous one, but isn’t as straightforward as the first one because you need to:
create a new entity by hand,
adapt the code to make it use this new entity,
potentially manage yourself the database migration to persist this new entity (depending on the nature of the changes).
More info: https://www.jhipster.tech/user-entity/
I was thinking about how to create a Proposal object like this in JHipster: so a User can create a Proposal and other users can vote for it.
entity Proposal {
proposalText String minlength(2) maxlength(100) required
proposalVotes Integer
}
entity Vote {
numberOfPoints Integer
}
relationship ManyToOne {
Vote{proposal(id) required} to Proposal{vote}
Proposal{user(id) required} to User{proposal}
Vote{user(id) required} to User{vote}
}
In Spring I would create that #Transient proposalVotes Integer and the Controller would go and find all the Votes that a Proposal has and add them together to get to the result to be sent to the frontend. That property would not be stored in the database.
If I use JHipster and I add a proposalVotes property, the result would be saved in the database and could be changed in the dialogs(... and I do not like the result), so my question is:
What is the best practice in JHipster when you need a property that is calculated everytime his object is called?
Think of the number of comments in a Blog with Posts, if it is more familiar.
Where do you calculate the result: I would do it in the ProposalResource, but I’m not sure and I haven’t seen any use case like this in the examples, but it looks like a common case.
Thanks a lot
PD: If there is any example in Github, that could be great!
Actually if you are generating entities using JDL(Jhipster domain language) then you wont get any option to make field Transient as JDL is database design mechanism and Transient fields are not going to be placed in DB.
Solution is that after importing JDL to our app you can add Transient fields in your entity class.