I'm new to jhipster, and have created a JDL file for Entities in my service using JDL Studio.
My goal is to keep iterating on my DB design, using JDL Studio, and then run the service so I can see the Entity screens that jhipster has created. How should I do this?
I have reviewed the docs on database updates, but I find it doesn't lay out this common development task clearly - wanting to iterate on a DB design. I see suggestions fo using jhipster entity ... but does that mean JDL Studio can only be used at the start of development?
My current process I'm hoping will work in some fashion is this:
Make changes to my entities in JDL Studio
Download changes to entities.jdl
run jhipster import-jdl entities.jdl
Tell it to overwrite everything - I have no customizations to the code yet in anyway.
Try and run the service using ./mvnw
I currently have very little code that is custom so far, and what I have is committed to git, so I can diff/revert changes if need be.
The problem is that I see to get conflicts, or the app breaks and won't compile, around things that seem related to the entities not being updated correctly. I'm perfectly fine with overwriting everything to just get the updated entities, and front end files
I've tried removing node_modules, target, and .jhipster/* files to see if I could cleanly recreate the entities, but it still has conflicts.
Note I'm only using H2 at this point, and don't plan on using liquibase/a real db until I actually release something, so probably months from now. Thanks!
As suggested in the question comments, the basic process is as I listed in my question. I think there were 2 things that solved my problem
completely removing the src folder, and allowing it to be regenerated
supplying both my JDL files at once on the command line.
I have 2 JDL files, one for entities, and one for relationships, which I broke out separately while trying to figure out how to best do these updates. I was running them separately as well, which worked fine for the entities JDL file, but wouldn't for the relationships one, as it needed the entities too.
So my solution seems to have been the following:
cd my_project
rm -fr src target
jhipster import-jdl entities.jdl relationships.jdl
If I found my entities weren't being regenerated, I also deleted the .jhipster folder, but not sure if this is required or not
rm .jhipster/*
Once again - I am completely new to jhipster, so there may be better processes, but this seems to have resolved my issues !
Related
I have made three different applications in j JHipster with monolithic. I need to merge these applications. I know that by using micro-services my quest can be easy but the current requirement is to do the merging with the monolithic pattern only.
I need to merge two applications with another or main application. I am using MySQL as database. I don't know where I need to change and how. Please help me out, I am a newbie in this scenario.
i tried to create a java file for setter getter methods and and a dao file for three databases and now in the main class file and am trying to take every dao file as an array of object and integrate it and put it into the third db.is it possible.i wanted to show the code bt,since i am new not able to maintain the coding standards to show.
by this i way i tried to involve three databases in a single scenario and want to complete my query through CRUD model.
as you already pointed out, the proper way of merging here would be using the microservice option, which you cannot take, as you are forced to use monolithic architecture...
almost automatic merge
if you did not changed anything to your code, after generating the entities, you just can put the contents of your applications .jhipster directory into one, and run yo jhipster --with-entities to regenerate the entities in one application. You should keep in mind, you will have to take a look at your main/resource/config/liquibase folder, to set the migration ids properly.
manual merge
For this you should be more experienced in the underlying technologies, as you will have to:
recreate your entity classes
recreate zour DAO/Repositories
(maybe) recreate your services, or service implementations
recreate your REST controllers
do a proper liquibase migration
provide some tests
migrate the frontend code, by adding states, components, templates etc..
the most of these things you just can copy paste already generated code.
For more information, you should ask more precise, what is not working, if you already tried something...
According to the documentation, after entering fields the wizard should ask me about relationships. Instead it skips this step entirely and just goes ahead and creates the files. I'm sure this used to work but I don't see what I could have done to break it?
I'd be happy to provide more info but not sure where to look.
Rather embarrassingly I've found the solution. It's been a few weeks since first installing jHipster and beginning to really try creating entities. I created a couple of simple ones to begin with and then played around with it to work out how I was going to use it.
Now I'm ready to start generating entities I looked at the website again and it says about these relationships. I think this is a new feature that has been added since I first installed jHipster though.
In the end I ran this
npm update -g generator-jhipster
And then when I tried to create an entity I got the question about relationships. Not sure if I need to somehow update my project to the new jHipster version now too.
How to update the JHipster project after updating JHipster generator?
I have a database project in Visual Studio 2012 with SSDT (latest as of this writing). In the database project, I have a schema called "UNITTEST" which contains tons of stored procedures that create, destroy, and provide other helper functionality for the unit tests. We do this because it gives us the ability to control our test data centrally rather than inside each unit test. Now that's fine and all however, I don't want to publish this schema or any of the objects inside of this schema to production.
So my question.. Is there a way to stop SSDT/VS2012 from including the UNITTEST schema in the production build deployment script?
I'm thinking there should be a way to do it depending on the solution configuration settings and publish profiles. If my configuration is set to "Release" then I want the build to perform a bit differently.
Builds are very new to me. I found this question: build-different-scripts-depending-on-build-configuration but I can't seem to get the answer to fulfill my problem. This question also doesn't help although it's very similar: bind-the-deploy-and-publish-destination.
Is anyone else managing something like this? The other developers in my team are just modifying the published script to remove these objects but I HATE manual work, there HAS to be a solution! :)
Thanks all!
One of my schemas references a lot of sys.* objects which created a lot of errors in the build. I created another project in the solution and moved that schema to the new project.
Luckily you can build and publish at the project level.
This allows me to keep the other schema in change control at least.
(It may also help to set the Properties on the SQL files to Build Action: None)
Partial/Composite projects might be useful here. Main project contains all of your necessary DB objects for your apps to run. The partial project references the main project, but then contains all of the "Test" code.
Here are a couple of options from Jamie Thomson:
http://sqlblog.com/blogs/jamie_thomson/archive/2013/03/10/deployment-of-client-specific-database-code-using-ssdt.aspx --This may be the simplest way to handle this
http://sqlblog.com/blogs/jamie_thomson/archive/2012/01/01/implementing-sql-server-solutions-using-visual-studio-2010-database-projects-a-compendium-of-project-experiences.aspx --Lots of good information in this post and most of it also applies to SSDT SQL Projects.
http://msdn.microsoft.com/en-us/library/dd193415.aspx - Composite projects for larger DBs. This could potentially work for you as well.
I have an XPages application that has been running quite happily for the last couple of years.
The application uses some Java classes as converters that are used to convert data entry on certain fields to upper case, proper case, etc. This functionality has been present and working since the app was first deployed.
Today I was asked to make a change to one of the pages, adding a new field. The change was made in a test copy of the database, the app rebuilt and tested and all was fine.
The same change was then promoted into the live database, but after being rebuilt the error
Can't instantiate class: 'Cannot find class uk.co.xxx.beans.UpperCase in NSF'.
is being returned.
I have tried rebuilding the app and cleaning the project numerous times without success. I have also tried amending the code in the Java class and rebuilding.
If I remove all references to the UpperCase class it then complains about the ProperCase class. It appears as if the app has lost its reference to the Java classes and rebuilding isn't fixing the problem.
As an interim solution I have removed all uses of these classes so that users can at least display the page - but this is obviously not a long term solution. As soon as I reinstate one instance and rebuild, the error returns.
The only change in the app has been the addition of the new field. Removing it makes no difference.
Can you suggest anything else I can try and what may be causing the problem?
Open production db in designer and using Navigator view open WebContent/WEB-INF and delete classes folder. Then rebuild the app or refresh it from template again.
Sometimes classes are not updated correctly. I've seen it few times.
I have seen this too (domino 8.5.3). I recompile until it eventually works. With a restart of the http task thrown in for good measure. How are you deploying the classes within the db or as jar files in lib/ext?
I ran into similar issues with 8.53 FP2 with the same "can't instantiate errors" if accessed by a designer client. I even put a PRD in at IBM for it.
In order to fix this problem we had to update to the server and clients to FP5. We had a work around before we could update the FP5. We had to modify how the application was rolled out. Once the database was updated from a template we had to do a clean then a build while use our Application ID used for signing applications.
http://www-01.ibm.com/support/docview.wss?uid=swg21639571
JDAE8ZV2CX
XPage With Java Design Element Breaks When Domino Designer opens after applying 8.5.3 Fix Pack 2 interim fix of any 853 Fix Pack 2/Fix Pack 3 hotfix
I am using MVC5 and EF6 CodeFirst migrations. My model is in a separate project from my MVC web app and I keep getting this error when trying to access the model classes. I have automatic migrations already enabled. I can drop the entire database and then using update-database to regenerate everything I still get this error. The error is wrong because the context has not changed since I created the database. Also, through a Unit Test project, using the same calling code as I have in my MVC app, I can reference the same Model project, access the model classes and data. I have the Model separate from the MVC project because I need to be able to reuse the Model outside of the web.
The model backing the "xx" context has changed since the database was created. Consider using Code First Migrations to update the database
Database.SetInitializer<DbContext>(null);
http://patrickdesjardins.com/blog/the-model-backing-the-context-has-changed-since-the-database-was-created-ef4-3
I got a similar problem :
The model backing the 'ApplicationDbContext' context has changed since
the database was created. Consider using Code First Migrations to
update the database
I have one project for MVC and another project for the model, context and repositories. I've been working on it for weeks but today it said stop.
I have tried to delete database, enable-migration, add-migration and update-database so many times that I've lost count. I've added initializers to MigrateDatabaseToLatestVersion as well as DropCreateDatabaseIfModelChanges.
What finally made it work was to move model, context and repositories into the MVC project (not something I was keen on)...then it worked right out of the box without any code changes at all (besides namespaces)! Very strange...
I've read so many blog posts during the day trying to solve this problem. One of them (I don't know which one) mentioned a bug in Visual Studio 2013 where reference to DLL files weren't always updated as they should, suggesting that my MVC project missed out something when I was running add-migration and update-database in my separate project. But it's just a guess.
I'm using EF 6.1 and .Net 4.5.1 in my solution.
Just to elaborate on RouR's answer:
I had an MVC web project that had a model attached.
I then created a console app that consumes this model.
My console app, only is aware of the connection string and has EF reference, just doesn't know how to let each one communicate.
Hence, the model backing database changed error appears
The engine is just confused how to proceed it sees and expects an entity, as was reference, just losses it when it fails to find the proper context, and assumes context wan't migrated properly.
So here we are,
Database.SetInitializer<MyProject.Models.MyModel>(null);
We are having the same issue. What solved it for me was not necessarily to move the Model, Context into the MVC project, but move my seperate project to the same solution as the MVC project and reference it by project folder.
This worked, but referencing a DLL instead of a project did not work.
Funnily enough, when creating a new Console Application and referencing the DLL assembly, we did not get this issue... only from an MVC project
We use EF code migrations to keep databases schemas up to date. The other day I had the same problem, in my case I was working with 2 database instances (QA and DEV databases of the same client with exact same data however QA environment was throwing this error. I've fixed the problem by deleting the _MigrationHistory folder and problem solved.