I've found that you cannot actually delete an entity, so I was thinking of doing a jhipster utility to delete entities (and find for relations, then cut them too), and if said searching works then add one to change an entity name.
That said, I was looking where I can find in jhipster generator the files that take domain over the file creation.
JHipster supports deleting an entity as its repositories extends JpaRepository, and its generated REST controllers also expose a delete action.
Related
Can anyone help me please? Right now i'm connecting my web API project to an existing database. Someone suggested to use EntityFramework for that. I'm applying code first approach in the "Entity Data Model Wizard", but the problem is i'm actually supposed to just import tables, but in the "Choose your database Objects and Settings" part, i accidentally imported views as well. so i was thinking to undo the import.
I read that after the Code First wizard, an app.config file should be added to the project, but this file is missing. The .edmx file is also not found. I've searched all files in folders but still not found. But when i looked at the ConnectionString tag in the web.config file, the new connection that i created in the wizard is there.
Please follow below steps to update the EDMX from database again:
Open the EDMX file
2. Right Click on the EDMX file and choose the "Update Model from Database"
3. In the new wizard go to the "Delete" tab and expand the Views
4. Check the Views you want to undo
5. Click on "Finish"
Hope this helps you.
First, a couple of remarks:
I'm applying code first approach in the "Entity Data Model Wizard"
Code First means that there is no .edmx file. There are migration files and code mappings.
I read that after the Code First wizard, an app.config file should be
added to the project, but this file is missing
Not 100% sure here, but I guess that if your project already has a web.config file it will be used instead of adding a new app.config file (they are basically the same).
So, the thing is that you have to enable and use code migrations, you have to generate POCO classes for your entities (if you don't have them already), and you have to add a database context that extends DbContext and includes DbSets for your entities, and some database initialization code.
This page explains how to do the most difficult part of all of that: dealing with the code migrations. Although it assumes that you are migrating from an existing edmx model and using Power Tools you can just ignore that part and focus on the useful information about the migrations. That is, skip directly to Step 2 in the page.
About removing the views you imported, I guess you didn't get to the part where you generate the migrations, so probably you just have to delete the POCO classes created for the views, and possibly also remove the DbSets added to your DbContext for those entities.
If you generated some migration you can either generate a new migration or modify the existing one. This can be done by adding explicit Ignore mappings for your view entities and running Add-Migration again. If you didn't get to the migrations part yet just ignore this last paragraph.
Hope it helps.
I'm trying to understand the different types of migration paths we can choose when developing an ASP.NET Core 1.0 application with EF Core. When I created my first Core application I noticed it generated a ApplicationDbContextModelSnapshot class that uses a ModelBuilder to build the model.
Then I read that if I need to add a table to the database, I need to create the new model and run the command line to generate the migration file and update the database. Ok, I get it up to this point.
But when I do that, I notice that the ApplicationDbContextModelSnapshot class gets updated too.
1) Does that mean I cannot modify this ApplicationDbContextModelSnapshot class since it looks like it gets regenerated each time?
2) Should I use Data Annotations to build my model or should I use Fluent API which tells me to build my model in the ApplicationDbContext class? Huh? another file that builds the model?
I'm seeing three different ways of working with the database here, the snapshot class, data annotations, and fluent API. I'm confused because today, I made a mistake in my last migration file so I deleted the file, dropped the database and reran the database update.
But by doing that I got errors similar to:
The index 'IX_Transaction_GiftCardId' is dependent on column 'GiftCardId'.
ALTER TABLE ALTER COLUMN GiftCardId failed because one or more objects access this column.
So naturally I was wondering if I had to modify the ApplicationDbContextModelSnapshot class.
What is the path I should be taking when it comes to migrations or database updates because these three paths are confusing me.
I have run into this issue before when I create migrations, make model changes, create new migrations, and try to update the database. The root cause is when keys are being changed and relationships are not dropped and are not added back or do not exist.
You have two options
Easy Method
The easiest way is also the most destructive way and only possible in a dev environment.
Delete all migrations, drop the database, create new migrations and run 'update-database'.
Hard/Safest Method
This is the most time consuming method. I recommend do this in a local integration branch first, pushing it to a remote integration, and then production.
Open the migration file, ie 20160914173357_MyNewMigration.cs.
Drop all indexes in order
Drop/Add/Edit table schemas
Add all indexes back.
For either method, just be sure to test and test again.
Do not modify ApplicationDbContextModelSnapshot. It is a design-time artifact, and should only be modified in the case of a merge conflict.
To update the model, always use data annotations or the fluent API.
For more information on the EF Migrations workflow, see Code First Migrations. It's for EF6, but most of the information is still relevant.
I am using RavenDb across multiple projects and solutions to access three different databases that are all part of the same product. For instance, I have multiple MVC projects that fetch user info and some data out of the 'web' centric database and the 'backend' database, using '-' for the id override (but I need this only for a subset of classes in the 'web' db). And then I have another 'backend' database that is used by services (as well as the MVC projects). And finally a third temp/scratch database I use by another set of services to build the backend db. And of course, all of these are being accessed from different class libraries and even console test, seed, and integration test apps.
Managing all of these is becoming quite a nuisance. Every time I create a new console app or class library that access the db, I have to setup config and raven packages for each project, make sure indexes are built, etc.... Not to mention running update on all nuget updates, or in my case, installing a new unstable version of the server/client binaries.
Is there an easier way to manage this?
I tried to abstract the DocumentStore creation and initialization, as well as index creation into it own project and reference that. But the other projects then had to manually add newtonsoft.json (and nlog) from the package directory.
As well, I am getting the following when I try and abstract the DocumentStore into a class with a static property:
StackTrace of un-disposed document store recorded. Please make sure to dispose any document store in the tests in order to avoid race conditions in tests.
Anyone have any thoughts on handling these issues?
Thanks
I don't think that the manual addition of the references is a big issue, but you can add the actual nuget references as well.
Note that the DocumentStore not disposed error is something that only happened in the unstable (debug builds), and won't happen on release builds.
I'm working on a project which involves aggregating data from a variety of sources so that users can search and mine it from a single front-end interface. The project breaks pretty cleanly into two components:
The cron triggered (Whenever gem) code that pulls data from various sources and POPULATES the database.
The front-end code that CONSUMES the data and presents it to the user.
I want to split the codebase into separate projects with a shared model to encourage clean separation of concerns but am not sure how best to go about that in Rails 3.
I saw this SO question about using a shared folder/submodule in SVN or Git but that doesn't seem very clean to me:
Sharing Models between two Rails Projects - using git submodules?
I come from a Java/MVN background were you would just create 3 modules (one shared and two that depend on it) and call it a day. Then with Maven you could invoke a build on the parent project and it would automatically update the shared code JAR in each dependent project.
Can the same be achieved using Rails Engines, Rake, and RubyGems? Or is there a better "rails way" to do it?
Thanks,
-James
You can keep the models in a gem/plugin. The DB configurations should remain in their respective apps, though.
I am building a composite (Prism) WPF application. I hava managed to build some core elemets: for example module discovery from folder.
I am also using NHibernate (Fluent) to persist data. I was able to separate modules so every has it's own model and mapping, and when Prism adds module it also adds mappings to my nh configuration.
What I would like to do is to insert some startup records when a module, that has never been started, is enabled.
For example:
When I first start my app, it detects that there is no db and creates one, only with one configuration table. This table contains info about which module is enabled. Then admin can configure app through UI which modules should be enabled. Next time the app starts it detects new tabs from newly enabled modules and creates their tables using NH UpdateSchema. What I would like to do is to also insert some startup records with this table create.
I think this should be done by NH events (NH documentation on events). Something like 'PostTableCreateEvent' would be nice but I can't find anything like this.
Did any of you do something like this?
Events are triggered in sessions but Schemaexport doest take sessionfactories or sessions, so you cant hook in there. For this what you want there is <database-object><create>INSERT ...</create><drop></drop></database-object> in xml mappings or plain sql since FNH doesnt support <database-object> afaik.
Option 1: add fluent and hbm.xml mappings on creation of NH-Configuration and embed Mappings with <database-object>
Option 2: allow Modules to take additional steps (sql) after Creation of tables ( for one of my projects i wrapped Schemaexport in my own class/Method which also creates the database itself which isnt handled by schemaexport and inserts custom data like schemaversion and configs)