I can't find any way to add a script to the clean action so I could delete the persistent store of my core data application when performing a clean.
Related
I have hard times on migrating one of our enterprise MVC projects to Core 2.1.
I want to move the project to the new structure Razor Pages + View Components from Controllers + Views/Partials. We have a ton of models and components and actions there.
When I convert projects I usually move things around, copy items to new paths, run automated refactorings, create new/change classes to fit the new requirements and design and that BREAKS the project. A build is the last thing I do when everything is already setup, just to see if I missed something.
Now after few refactorings and breaking changes I can't add new items(razor pages, view components and so on) just because project is not buildable.
"There was an error running the selected code generator: Failed to build project..."
Basically it forces me to do everyting manually, check every copied/migrated piece of code just to add a new item !
I'm in nightmare, please someone wake me up, how to disable this thing ? or suggest a migration strategy for large projects.
First, and most importantly, adding a item via scaffolding will always kick off a project build. The scaffolding needs the project to be in a consistent state in order to function correctly. There is no way around this.
Aside from that, Visual Studio will only rebuild on changes if you're actually running the site. So if you've got it running in IIS Express, kill it to avoid that.
For what it's worth, it's better to correct errors as you go, anyways. It much easier to process a few errors at a time than hundreds all at once, and you'll also then be able to take advantage of Visual Studio's refactoring features, which only work when the project can build, making the total amount of work you have to do usually far less.
in MVC:
Add -> View adds scaffold without build
in Core:
Add -> View adds scaffold + build
Add -> New Item -> View adds without build
So if you don't want to run build on every single add in Core use
Add -> New Item -> ...
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.
Am developing an application using core data. Every time I delete the application from the emulator all the data that was inserted using core data is deleted. does this mean when i publish my application my data base will be empty? I want the data base to have values when i publish it or install it to anther device.
You can create a database and package it inside your application bundle for distribution. Then, whenever your application starts up, before using any data it can check to see if there's a copy of the database in the working directory. If not, it should copy the packaged one.
I want to create a large database. I am thinking of using core data for this purpose.But i want to insert the data to it manually and only once. This data is never deleted or edited but only read. How can i use core data to add such large number of objects to database? How to create database in core data and write only once.
Your question is quite general but I'll try to give you some hints on it.
Based on my experience, the simplest way to achieve it, it's to follow these two steps:
1) You could create an external file, in XML, JSON or plist format, that you can parse and use to create a prepulated a Core Data store. You can find some info in core-data-tutorial-how-to-preloadimport-existing-data-updated. In particular, you could set up a dummy project (or just use the AppDelegate methods) and use it to create the store, e.g. MyDataStore.sqlite.
2) Once you created, forget about the routines you have previously used and you ship the store in the application's bundle of your app. There the store is read-only. Otherwise, if you need to modify it, you are not allowed to do it and so you need to move it, for example, to the document directory.
You cand find additional info in the following SO topics:
Is Core Data useful for readonly data too?
How can I ship my app with a pre-populated Core Data database?
Core Data Store included in App Bundle
P.S. If you are in production and you need to make same change to your store, you need to republish the app (since the store is within the main bundle). To avoid this you need to move the store to a different directory and set up, for example, a sort of sync mechanism.
Hope that helps.
I developing an app that is read-only. The data has relationships, so I cannot just use a plist or something similar.
Questions:
Should I use Core Data for such a requirement?
If so, how would I enter the data and then release the app with that data?
How would I make it so that the app doesn't need to re-populate a DB every time it loads?
Is there a way to create a Core Data model using sql commands with sqlite (i.e. insert into, etc)?
You may use an SQLite database to accomplish this.
Create the model in your iOS app.
Create and populate the database in a Mac OSX utility command-line app
Copy the sqlite file into your iOS app and link it with some code
Work through these two tutorials, line by line, and afterward you will have a good enough understanding (and code sample) to complete this task in your own app.
Core Data on iOS 5 Tutorial: Getting Started
Core Data on iOS 5 Tutorial: How To Preload and Import Existing Data
In my short experience with the iPhone, you have two options.
Write a data import function and run it on the first application launch.
Use solution 1, but build the initial sqllite file in the simulator, and then on first application launch, copy it into the app's documents directory.
From past experience, option 2 is much quicker for user experience, and the preferred solution.
You can write a utility project that imports the app's data model and use throwaway code n that project to populate the Core Data DB. Once the DB is populated, simply copy the actual file to the app project's resources folder and then when you set up your persistent store, use NSBundle to return the path to the DB file within the built app.
And you're done.