We Keep Coding

Automatic migrations doesn't work [EF Core] [closed]

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
I tried to automate migrations in my project so added a 2 lines
_context.Database.Migrate();
_context.Database.EnsureCreated;
But i can't see any updates in my database. Why?

Automatic migration has been removed from EF Core. This feature is not present in EF Core 2.0. There is no plan to add this feature to EF. Microsoft thinks it benefits is less than its drawbacks.
There are 2 methods in EF Core 2.0 related to migration. Database.Migrate() and Database.EnsureCreated(). Neither of them are a complete migration.
Migrate() does not add or create a migration. It only checks if any not-applied migrations exists or not. If yes, then updates the database based on them.
EnsureCreated() creates the database based on the models in the project. But it does not do this in the migration way. Actually no migrations are needed by this method. Disadvantage of this method is that a database created by it, can not be updated in future by any migrations. Indeed this method is added to EF to help people create projects fast in MVP style.
Conclusion: First add migration and then do update database ( Database.Migrate())

How to persist views for ADO.NET EDM when database is recreated [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I am working on a project that started with code-first POCO objects representing database structure. For development purposes we use drop and create when database is changed.
There is a new requirement for providing support for OData queryable endpoints. So I created new ADO.NET Entity Data model (generated from existing database).
I would like to use EDM only for retrieving data from database views.
But as far as I understand there is no way how to specify them "in code" so they would be persisted in the EDM. And if I create a view in the database, regenerate EDM and then change the code-first structure, the DB is regenerated and view is gone.
This is a problem only for development phase but a big one.
Only solution to this problem I can think of is to keep a SQL definition of all views and execute them when Entity Framework is creating the database.
Is there a better way?

Code first approach does not support creating Views. So you have to look for other options. I would suggest creating migrations (auto upgrade works in most cases) and avoid using drop/create method. This would preserve Views and keep all the benefits of code first.

.NET Entity Framework, clean way to implement it? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm currently learning LINQ especially SQL requests with the entity framework.
I used to write native SQL-queries before, and I've implemented it with one class in my projects called "SQL_Connection" or something.
So I had all my SQL-procedures stored in one class.
Now as I'm willed to learn the entity framework the right and cleanest way from beginning, I'm asking myself where do I put all those linq-procedures I create during a project.
Do expierienced people put them in the class-file of the related class, or are they using a big sql-class where all those procedures are stored in?

I'm asking myself where do I put all those linq-procedures I create during a project.
Where you create them.
If you are not totally ignorant on .NET you will have a TON of LINQ queries and only SOME will be EF related - the syntax is the same. You will use LINQ in your code to sum and aggregate in memory arrays, and do a lot of things.
The beauty of LINQ is that all changes to the underlying provider are isolated and / or checked by the compiler, so there is no need to have all in one place "in case I rename a table".
I keep the LINQ where I need it. This allows me to isolate layers without having a mother of all queries class. Especiall as some of the LINQ queries are multi step queries involving one or more data access then grouping and correlating in memory.
Seriously, the "one class to rule them all" (sql) is an artefact of the fact that SQL is a string, so in case of a database change you need to find all SQL that touches that changed element and that please without going through tons of code. This is absolutely not needed with LINQ.

That's up to your pleasure. Answering the question: do create BLL classes for your related set of objects. By this, a minor change won't make you itchy. Assume you added a new column to a table, having that table's (and other related ones') operations located easily is good, right? Avoid too big files. Try to stay modular and etc.
If you need a reading, check out this Wiki link about MVC architecture.

Table designer (Entity Framework) is too resource intense [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm working on a project that we're using .NET MVC 3 and EF 4. The website is growing and there are a lot of tables. So, the table designer of Entity Framework too much CPU usage t open and add new tables. What are my options? What can I do?

For larger models, I think the designer approach is less desirable. If you can, consider refactoring (one bite at a time?) to a code-first approach; this will allow you to keep using current technology. I have a project with ~650 entities working perfectly fine, but I can't imagine loading a .edmx designer with ~650 entities (without pulling my hair, that is).
All in all, it's not EF that's "heavy" - it's the designer.

Starting with Visual Studio 2012, you can now split your Entity Model into multiple diagrams. This'll reduce the diagram complexity a lot.
See
http://msdn.microsoft.com/en-us/magazine/jj721589.aspx
http://msdn.microsoft.com/en-us/data/jj519700.aspx

If you database operations are large in general you may consider not using EF and use raw ADO.NET instead. EF boils down to ADO.NET at the low level anyway but using ADO.NET right away will improve performance.

Moving to a code first architecture is definitely something to consider for the long term. For the short term, you also might be able to break your model up into multiple design contexts. You can start this by identifying areas of the application that only use a subset of the tables. Then create a separate data context that only includes those tables. You can keep the existing omnibus context around while you're working on this to avoid breaking legacy code. You can add as many data contexts as you like, but I would create each one in a separate folder (and therefore a separate namespace) so you don't have to worry about name collisions.

How to Migrate from Plain Entities to Self-Tracking Entities? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm working in a project that uses .NET Entity Framework 4 with EntityObjects. Since we have found that we need to evolve into self-tracking entities for the remaining modules that haven't been implemented, I want to ask this:
1) Can we delete the existent plain entities and regenerate self-tracking entities from the database without modifying our currently written code using them?
2) If the answer of 1) is 'yes', is that easily done? How would you proceed to migrate from the first scheme to the second?

Change the namespces of your existing POCO classes to the one you expect EF will generate and so that your references will be updated.Then delete old POCO classes and generate EF classesThen compile your solution

By plain entities i presume you mean POCO's. You probably need to delete the POCO classes u wrote or generated and set the build action of the edmx file to EntityDeploy.
Hope this helps.

You just have to remove any old T4 you may have used (if you used POCO T4), and add new self tracking POCO T4 from your model.
It should be enough to work.