I have create my app with jhipster in july, and i have put it in production.
Now i need edit a entity.
When i use jhipster entity the subgenerator update the initial xml generate for the entity, but not is thes the correct work, the code need create a new xml with the update like: mvn liquibase:diff
Searching on the web i have foud this answere: Add new field to existing entity with JHipster. At a certain point the user say:
create a new migration file to add only the new column (see addColumn
documentation), revert the creation migration to its original content
using git, run your app to apply changes to your database. This is
what you would do when your app is in production.
In reference the last phrase, is the true? Jhipster entity subgenerator not support update of db but only initial creation?
tks
Yes it's correct.
Either you write a manual Liquibase migration or you use liquibase:diff to help you in this process.
See official docs: https://www.jhipster.tech/development/#database-updates-with-the-maven-liquibasediff-goal
Related
I am new to Jhipster application.
I have created entity. But now i want to delete this entity.
could you please anyone tell me about command and help me on this activity.
Unfortunately, it must be done manually.
The easiest way is to revert the git commit of the entity creation. This is why it's a good practice to always commit after entity creation.
Beside deleting files, you may also want to create a Liquibase changelog to drop the entity's table.
In previous spring boot apps I have worked with, hibernate has been whats taken care of changes to the database, whether it be the data imports on startup or modifying the database if the entity's change.
So if I changed an entity the spring.jpa.hibernate.ddl-auto setting would be what determines how the database is changed. Is liquibase what is doing this in a jhipster app? I'm mostly concerned about what liquibase does to modify the database, apposed to the versioning aspect
The Liquibase creates 2 tables for its own purposes DATABASECHANGELOG and DATABASECHANGELOGLOCK.
DATABASECHANGELOG keeps records of what all changesets have been applied on the database so far.
JHipster uses Liquibase to manage the database updates, and stores its configuration in the /src/main/resources/config/liquibase/ directory.
If you prefer (or need) to do a database update manually, here is the development workflow:
Modify your JPA entity (add a field, a relationship, etc.)
Create a new “change log” in your src/main/resources/config/liquibase/changelog directory.
Add this “change log” file in your src/main/resources/config/liquibase/master.xml file, so it is applied the next time you run your application
If you want to skip Liquibase migrate task during startup application, you can using profile "no-liquibase". Ex: spring.profiles.active=prod,no-liquibase
More information on using Liquibase, please go to http://www.liquibase.org.
So for our use case all of our custom entity's already exist in the database. We dont want liquibase to handle any changes/updates to the entities in the database. I know this can be achieved by using liquibase.enabled: false in the yml file for the relevant profile. We will be using a hibernate setting to not start the app if the mappings to the database table arent correct.
However we would still like the JHipster generated classes for User/Authority/etc to be generated. Jhipster handles this with liquibase. I know on 1st application run up I can run with liquibase enabled and then from then on run with liquibase disabled?
Is there a better workflow for this I could do through configuration?
You can run Liquibase as a command line tool. In my project, we modified our pom.xml so that the build generates both the app jar and a zip of the Liquibase migrations, both artifacts are deployed to a Nexus repository and our deployment process (based on Ansible) executes Liquibase on unzipped migrations retrieved from the Nexus repo.
In addition, you can also use Liquibase contexts to restrict some migrations to some environments only: e.g to init admin password only in dev or test.
Is there a systematic way to incorporate data migration scripts with an SSDT publish?
For instance, deploying a new feature that requires a new permission be added to the database in the form of a series of inserts.
I know I can just edit the generated publish script, but if the script needs to be regenerated you have to remember to re-add the data migration scripts.
The recommended practice is to use a post-deployment script. This blog post describes the approach further:
http://blogs.msdn.com/b/ssdt/archive/2012/02/02/including-data-in-an-sql-server-database-project.aspx
I have an app that I have been working on and I did a bunch of changes and then realized later I should have been adding versioning to the Core Data model. So I'm trying to go back and do that now.
Basic information:
I think everything I've done would fall under the lightweight migration feature.
I'm using git
I already have the app in user's hands
My question is: what is the easiest way to do this?
Since I'm using git, could I simply checkout the data model from when I submitted it to apple, create a new version for it, and add my changes? My main fear with this idea is that my project.pbxproj file would be incorrect. Would this an issue? Is there a way to get around this?
IF I could do this, would I need to recreate my class files or would that be ok (assuming I get it back to being identical to what I currently have).
IF I CAN'T do this, then what can I do? If its a matter of starting from the last version I pushed to Apple and applying changes I guess I should look into doing it with git rebase, right?
This has nothing to do with git.
You need to create a new version of your app, provide the new data model, set it for lightweight migration and then release it as an update. Core Data will basically assume that any model without version info is version zero and attempt a migration to the new version.
When the user downloads the update, the automatic migration will trigger the first time the app runs.
Creating a new version means nothing more than changing the version number in the project info. When submitted, that will trigger the upgrade and the migration.