As part of JHispster 2.11.0, the entity configuration is saved in a specific .json file, in the .jhipster directory. These files can be used to regenerate entities and related files in JHipster application using the below command.
yo jhipster:entity ENTITY_NAME
Is there any way to auto generate those .json files from existing database?
We are currently working to generate those files from a UML model, see our JHipster UML project.
So if you can export your database schema to UML, this could be doable, but I don't think this can work as smoothly as expected.
Related
Let's say I have a class that extends DBContext (hereby called DBContext for simplicity) defined in a shared library plus an extension method to simplify adding this DBContext to dependency injection (given a configuration variable, it will generate a connection string to the database).
How would I go about applying the database schema? From the shared library? From a binary that consumes this library?
It's my understanding that when you apply a schema to a database a migrations folder is created and I want one canonical place where these migrations go.
If I run dotnet ef database update from the shared library, how does it know where the database is if I'm not providing configuration? Where would I provide configuration (like which database server and what credentials)
This shared library will likely be used by many consumers, so having migration scripts on each project sounds like a bad idea. Any suggestions?
Place the Connection String inside configuration for your Startup project (appsettings.json or other) and pass it to your extension method in your library.
Leave the Migrations in the library project with the DbContext. When you run dotnet ef database update you can provide separate --project (the project with your DbContext and Migrations) and --startup-project (the project that actually consumes your library) options.
https://learn.microsoft.com/en-us/ef/core/cli/dotnet#using-the-tools
The startup project is the one that the tools build and run. The tools have to execute application code at design time to get information about the project, such as the database connection string and the configuration of the model. By default, the project in the current directory is the startup project. You can specify a different project as startup project by using the --startup-project option.
I've a scenario where the project structure as following
DomainModels
Repository --ReferenceTo 'DomainModels'
Curator --ReferenceTo 'Repository'
MVC project -ReferenceTo 'Curator'
Now the problem is If I keep My DbContext in DomainModel which I'm supposed to keep, I cann't enable Db Migrations.
-- The only solution I've come across is to give the reference of 'DomainModels' to 'MVC projects'
using Enable-Migration MigrationName SomeAdditionalParameter here
Why is this a problem? I have a Data project which contains the models and DbContext. My web and business projects reference this. When I run the Add-Migration step, I just select the Data project in the project dropdown and it uses the connection string in the web.config in the web project. It works well and I have no problems.
I have a data access project that includes an .edmx with templates and so on. Now, when I add this project as a nuget package and then fetch/update it in another project the database model files are created from the template. This is not really what I want.
Is there something wrong with my design in all this or can I disable this behaviour?
I just need to delete the generated files and everything works fine, but it's mighty annyoing.
Thanks for any advice.
Using EF6 and Database First, I created custom T4 templates (*.tt files) in my VS2013 class library project. I don't want to migrate the app.config file with my assembly so I delete it. When I Update Model from Database, it presents me with a connection to select (I believe this is stored in the Visual Studio user preferences). If I choose not to store this in the app.config, it continues to show this step in the Wizard. Whenever the connection selection step is presented and the wizard completes, I notice the EDMX generates the two default *.tt files alongside my custom ones. Any way of preventing this? I read an article about EF code-based configuration and I tried DbConfiguration.SetDefaultConnectionFactory but that didn't help. The EF wizard always wants a connection in the app.config. Is there any way around this?
I ended up leaving it in the app.config (on my machine) and do not migrate this file to our development/test/prod environments. It's become a manual task to confirm each app.config file since it has become necessary to migrate some files due to adding project assembly redirects.
My ASP.NET MVC 2 application uses Entity Framework 4.0 for the data model. Following the instructions on http://blogs.msdn.com/b/aspnetue/archive/2010/09/17/second_2d00_post.aspx I put the .edmx in its own assembly so my solution has two projects:
MyApp.Core (ASP.NET MVC 2 Web Application Project, references MyApp.DataLayer)
Models/
Controllers/
Views/
Web.config
MyApp.DataLayer (Class Library Project)
Entities.edmx
App.Config (<-- generated by edmx when I update model from DB)
When I regenerate Entities.edmx, it creates the App.Config file under MyApp.DataLayer with connection strings to the database. The problem is that when I deploy the solution, the Web.config is the only config also deployed, so I have to manually add these connection strings to it otherwise I get an exception at runtime because they cannot be found.
I'd like to not the same connection string defined in both Web.config and App.Config. How should I organize my projects/config files such that the connection string to the db are found in only one place? Is this possible?
You can either embed the autogenerated app.config in your Model project and reference the connection string when you create your DataContext using GetEmbeddedResource...or (the more normal approach) copy the connection strings manually from the auto-generated app.config to your web.config.
If you want to be really ingenuitive, create a simple T4 template that copies the app.config connection strings in your web.config when you generate the EDMX model.