Run this and see what happens for tables without a primary key:
Scaffold-DbContext "Server=xxxx;Database=yyyy;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer
Hi. The code generation is pretty cool and a big time saver. While EF might not be able to handle it when there is no primary key, it would be awesome if the code generated the class files for the tables anyway. And even go all the way or as far as it can in the DBContext file. That would still allow us to continue with manual changes (if there is a database or political reason that we can not add a primary key) or just continue with adding our own queries and not using some of the built-in functions like .Find. I presume that we still can query with EF without a primary key. Maybe we can even do updates and inserts? I think that the primary key absence would only affect some features like caching or whatever.
Long term I'd guess if there is no primary key, or if the key contains multiple fields, you can just have the system generate its own such thing in memory composed of the combination of all the fields, maybe produce a unique hash code from them. Obviously slow, but provides the functionality, should someone choose to use it.
But anyway, the point of this ticket is at least to allow the PowerShell scaffolding script to at least output the tables into Classes and do as much as you're willing in the DbContext because just that would be a big help for situations where the DB schema is just not entirely in our control. This example is a schema that's used by an ERP software, and we know how great some of those old ones are at keeping database relations OUT of the database. :)
EF Core version: 1.0.0-rc2-final
Operating system: Win10
Visual Studio version: 2015
Other details about my project setup:
Using: Scaffold-DbContext "Server=xxxx;Database=yyyy;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer
FWIW I think read-only mapping for tables and classes without keys would be reasonably useful and not extremely complex to allow. Updates and deletes on the other hand are fundamentally key-based in EF and inserts also require keys if there are any values generated in the database that need to be retrieved.
The old EF6, Linq2sql allowed us to map such tables and then manually define which field should be treated as PK.
Some older databases (especially CRM) do not have the reputation to use relations heavily, in my case there is a table where (according triggers and unique constraints) there are some fields/candidates for PK but there's also a singke KeyID auto-identity column too. Currently i'm not able to generate code for it (the table has around 50+ columns - may even be 100+) and set the PK manually...
See also #1679, which is specifically about supporting views
is this solve? any current update?
Note, if there is no primary key defined, we could fallback to using a unique constraint/index if there is one.
Now that EF Core has query types, the scaffolding could generate those for tables without primary key.
@BalassaMarton Yep. I was going to look into just that as part of #1679
@bricelam hows it going with this?
I am facing the same issue
Any updates on this @bricelam ? Many thanks.
Blocked on #14194
@bricelam the issue you are blocked on is closed.
@bricelam Does this feature require any changes to the Scaffolders?
@ErikEJ - Yes. And it will also enable generating views. Probably we will generate HasNoKey.
@smitpatel @ErikEJ Can this be closed?
This issue was marked as closed-fixed but I can see the problem persists.
I'm working with .net core 2.2 and Microsoft.EntityFrameworkCore.SqlServer 2.2.4.
Is there a plan to work on this in the future?
@tico321 This is marked as fixed in the 3.0.0-preview6 milestone. This means it is fixed for EF Core 3.0. not for 2.2.
@ajcvickers, any chance this will be backported to an update of 2.2.6? It would be nice to use it with .NET Framework too.
@tellarin Unfortunately not, sorry.
Most helpful comment
FWIW I think read-only mapping for tables and classes without keys would be reasonably useful and not extremely complex to allow. Updates and deletes on the other hand are fundamentally key-based in EF and inserts also require keys if there are any values generated in the database that need to be retrieved.