locked
Schema first being phased out in .Core??? RRS feed

  • Question

  • User-1245365310 posted

    Hi,

    Is it true that schema first is being dropped from asp.net core leaving only code-first?  

    Does all the .Core articles apply to VS2019, or only VS Core?  

    How are articles written in .core used in VS?

    What won't work?

    Confusion, confusion...

    Thanks,

    Stanley

    Friday, October 16, 2020 7:26 AM

All replies

  • User-821857111 posted

    Are you taking about the Database First approach that depends on a generated edmx file? If so, yes. You are correct. It is not supported in .NET Core.

    Does all the .Core articles apply to VS2019, or only VS Core?  
    There is no such thing as VS Core. Do you mean VS Code? You can use VS 2017 onwards for .NET Core development, and you can use VS Code.

    Friday, October 16, 2020 7:38 AM
  • User753101303 posted

    Hi,

    You can still choose either code first or scaffolding (generating code from an existing database) but you can't start with a model designer tool aka "Model First" :  meant https://docs.microsoft.com/en-us/ef/ef6/modeling/designer/workflows/model-first

    Friday, October 16, 2020 9:40 AM
  • User-1245365310 posted

    Hi Mike,

    >> Are you taking about the Database First approach that depends on a generated edmx file?

    I understand there is a schema-first, model-first and code-first, whereas schema-first never does any changes to the database, instead it just reads the database to do (maybe create the edmx?).  I really don't want anything that modifies the tables as I want to that work within SSMS or RedGate.  I just read that even the model-first type actually drops the table and data then builds new ones without the data.  Dropping data this way is totally unacceptable,  It also stated to avoid that, one has to hack the generated script.  Looks like problems just waiting to happen.

    Also learning that all other Entity types other than code-first is being dropped from Entity as I've heard that MS is trying to move all the VS stuff like Entity to VSCode for a single code base.  If this is all true, then I'm questioning this whole MS stack stuff.  It seems their tool's life cycle is way too short.

    I'm just now learning all this C#, MVC, Entity, Identity and other stuff and trying to find the best path forward.  Then I learn that soon, VS will be replaced with VSCode.  I already see the reshaping of Entity that suggests there is some truth to this.  I really need some direction in all this...

    Thanks, Stanley

    Friday, October 16, 2020 6:28 PM
  • User-1245365310 posted

    >> you can still choose either code first or scaffolding

    Does the scaffolding mess with the data as the article you mention said that model-first blows it all away.

    Thanks, Stanley

    Friday, October 16, 2020 6:31 PM
  • User475983607 posted

    I just read that even the model-first type actually drops the table and data then builds new ones without the data. 

    If that were true, code-first would be unusable.   But it is possible to mess up and drop a table.  That's on you for no paying attention.  You should always review the migration file before executing update-database.  It is very simple to undo a migration, fix the problem, then add the migration again.  There's also the option of creating an empty migration and adding whatever code is needed including standard TSQL.  

    Also learning that all other Entity types other than code-first is being dropped from Entity as I've heard that MS is trying to move all the VS stuff like Entity to VSCode for a single code base.  If this is all true, then I'm questioning this whole MS stack stuff.  It seems their tool's life cycle is way too short.

    I'm just now learning all this C#, MVC, Entity, Identity and other stuff and trying to find the best path forward.  Then I learn that soon, VS will be replaced with VSCode.  I already see the reshaping of Entity that suggests there is some truth to this.  I really need some direction in all this...

    Can you share the official link?  Seems rather unlikely.  

    Friday, October 16, 2020 7:08 PM
  • User-1245365310 posted

    And how does this play into going forward...

    Supported platforms

    EF Core 3.1 runs on .NET Core and .NET Framework, through the use of .NET Standard 2.0. However, EF Core 5.0 will not run on .NET Framework. See Platforms for more details.

    Friday, October 16, 2020 7:34 PM
  • User-1245365310 posted

    >> It is very simple to undo a migration, fix the problem, then add the migration again. 

    Are you saying I can undo a migration that gets all the data back, fix the problem and add back the migration. 

    I would much rather never use a migration, instead deal with database changes at the database level as there are many more non-C# apps that relies on the database.  I see the risks far too high for any automated process that could fail when dropping a table.

    Thanks, Stanley

    Friday, October 16, 2020 7:44 PM
  • User475983607 posted

    deedroom@hotmail.com

    And how does this play into going forward...

    Supported platforms

    EF Core 3.1 runs on .NET Core and .NET Framework, through the use of .NET Standard 2.0. However, EF Core 5.0 will not run on .NET Framework. See Platforms for more details.

    I do not understand how the compatibility list has anything to do with your previous statements.

    deedroom@hotmail.com

    Are you saying I can undo a migration that gets all the data back, fix the problem and add back the migration. 

    No.  The add-migration command generates a migration file.  The migration file is empty if there are no changes to the DbContext.  If there are changes to the DbContext, those changes are applied to the migration file.  The standard advice is reviewing the migration file to make sure the file contains the expected DDL.  Undo the migration if there are any problems with the code, fix the issue which is usually a missing attribute or join, then add the migration again.  Executing update-database runs the DDL code against the database.  

    You'll lose data if you see drop table in the migration file and still execute update-database.  I've used code-first migrations for a few years and I have never had an issue with dropping a table.  If you run across an edge case where a table must be dropped then you can always store the data in a temporary table.  Then reload the data once the table recreated.  This is no different than dropping a table with SSMS. 

    deedroom@hotmail.com

    I would much rather never use a migration, instead deal with database changes at the database level as there are many more non-C# apps that relies on the database.  I see the risks far too high for any automated process that could fail when dropping a table.

    You are making up a problem that do not exist.

    Friday, October 16, 2020 9:10 PM
  • User-474980206 posted

    MS dropped support  of mdex files, actually, the GUI support. They switched to scaffolding tools instead. So database first is still supported, only the tools are changed. If you want a GUI entity relationship tool, you will need to go third party.

    I generally only do database first, as I like to abstract the debase with views and stored procs. I typically use a database project, and use its deployment features. Azure data studio now supports dpac deployments and they are easy to script.

    Saturday, October 17, 2020 1:18 AM
  • User-1245365310 posted

    You are making up a problem that do not exist.

    Not true, as these sql tables have 4 different VFP maintenance apps that does crud operations on the data. 

    I have no time for making up anything as I'm trying to solve the right tool set now...

    The data is also huge at 80gb per table file, therefore making dropping tables of this size impractical due to the many checkpoints, log backups and truncs and other operations, just to get it all settled down, after getting the full text and other indexes rebuilt

    Saturday, October 17, 2020 3:06 AM
  • User-1245365310 posted

    They switched to scaffolding tools instead

    I'll take a look at this scaffolding stuff via Google as it looks like you are doing it more like the way I want to by reducing the apps complexity by dealing with the database at the database level.  Are these tools separate apps, extensions, or what?  What should I be looking for?

    Just wondering how all the code-first fans deals with a database admin that must approve all changes made to the databases they manage?  Just curious?

    Saturday, October 17, 2020 3:15 AM
  • User475983607 posted

    deedroom@hotmail.com

    Not true, as these sql tables have 4 different VFP maintenance apps that does crud operations on the data. 

    I have no time for making up anything as I'm trying to solve the right tool set now...

    The data is also huge at 80gb per table file, therefore making dropping tables of this size impractical due to the many checkpoints, log backups and truncs and other operations, just to get it all settled down, after getting the full text and other indexes rebuilt

    What exactly is your point?  Code first does not affect standard DB maintenance.  Why are you focused  on dropping tables?  Code first does not drop tables.  Share your code if you are having a problem with code first dropping tables. 

    deedroom@hotmail.com

    Just wondering how all the code-first fans deals with a database admin that must approve all changes made to the databases they manage?  Just curious?

    Code-first fans?  What does that mean?  Developers that are bias and only use code-first?

    Making design decisions is one of most basic tasks experienced developers face.  It's vey simply.  Use right tool for the job.  If Entity Framework is not the right tool then don't use Entity Framework.  You posted several times and each post is a different subject from the previous. As far as I can tell you are trying to find faults with EF Core rather than evaluating the framework for use in your project.  

    I too take advantage of the database project in Visual Studio to sync procs and views with the database and source control  I use this approach with a database that was created well before EF.  The database is mostly Views, Stored procedures, Jobs, and a little sprinkling of SSIS.  There's no reason to move away form original design approach..  This DB has been operational for years and many other project depend on the design.  As time moved forward, a secured Web API service layer was built to interface the DB other remote entities.  The Web API project uses Entity Framework Core and it works great - no complaints.

    Lastly I want to mention, peer reviews are not a problem with code-first.   TSQL script can be generated directly from the migrations.  This is covered in the official documentation.   Also explained above, developers have total control over the T-SQL that is generated.  I'm not advocating code-first.  I'm highlighting a possible bias on your end.

    Saturday, October 17, 2020 11:49 AM
  • User-821857111 posted

    I just read that even the model-first type actually drops the table and data then builds new ones without the data.  Dropping data this way is totally unacceptable,  It also stated to avoid that, one has to hack the generated script.  Looks like problems just waiting to happen.
    The article that was linked to relates to EF 6 and EDMX files. I've never used EDMX files, so I don't know if that's how they work. However, since support for them has effectively been dropped from .NET Core and .NET 5, it's not a concern. I've never known a code-first migration drop a table except where it is intended because it is no longer needed, or it is in the code that is designed to reverse the migration.

    I have heard nothing about VS Code replacing Visual Studio. That idea makes no sense to me at all. VS forms part of the old MSDN subscription. They are still selling those (https://visualstudio.microsoft.com/vs/pricing/) No mention of dropping the product at all. VS Code is free. Perhaps you could provide the source of that suggestion so that we can get some clarification?

    Monday, October 19, 2020 6:32 AM
  • User-474980206 posted

    EDMX support was dropped with VS2015 (just another dead MS technology), its unrelated to .net core. As it is unsupported, it was never updated to .net core or .net standard.

    as stated many code first tools will generate scripts the DBA can use.

    whether you use database first or code first, you can run into schema changes that require replacing the table. 

    Monday, October 19, 2020 8:14 PM