Some lifecycle events – such as EF 6’s ObjectMaterialized and SavingChanges - are conspicuously missing. It’s being tracked for future implementation ( ). Much better than writing SQL as hardcoded strings, don’t you think? Yes, I do know that there are third-party extensions out there that already do this, but it would be nice to have this built-in. Take this hypothetical strongly typed delete on top of a LINQ query, for example: var deletedPosts = (p => p.Timestamp.Date < (-365)).Delete() One thing that would be nice and already exists on other ORMs is the ability to batch perform DML operations from LINQ queries, for example, UPDATEs and DELETEs. This is also currently scheduled by the team for a future release ( ). Expressions for CUD OperationsĪnother useful operation, the ability to use raw SQL – which could even be a stored procedure call – for Create, Update, and Delete (CUD) operations. Of course, that property would not be persisted. True, we can have a whole entity coming as the result of a view, or a raw SQL, but this is a different thing. There are plans to introduce it in the future ( ) Expression ColumnsĬurrently there’s no way to map a column to a SQL expression, which could be very handly. There are three canonical table inheritance patterns:Ĭoncrete Table Inheritance / Table Per Concrete Class (TPC)Ĭurrently, TPH and TPT are already supported, but TPC is not. Plus, you don’t have semantic collections such as sets or bags, or indexed collections such as lists or maps. You can’t have collections of primitive types without using a value converter. It can be lazy loaded, in which case, you need to declare it as ICollection or IList, or not, but that is it. Collection TypesĬurrently, EF Core only supports one type of collection. I’d like to have a truly extensible primary key generation mechanism on EF Core. If we have a client-generated primary key, batch insertion is possible, which can be a great benefit. While this is fine, it does prevent batch insertions, because it requires obtaining the generated primary key after each inser ( SELECT SCOPE_IDENTITY()). I dare say that EF Core is slightly biased towards SQL Server and, even more, that most SQL Server folks are used to having IDENTITY as their default primary key generation strategy. If it were implemented with just standard DML commands, it could be made database-agnostic, for the benefit of all. HiLo is a great pattern for generating primary keys, but, unfortunately, the way Microsoft implemented it, resorting to database sequences, makes it database-specific – currently, SQL Server only. NET Core 3.1.For GUIDs, EF Core automatically generates, on the client-side, a new value before inserting, which is nice. Provisioning.ConsoleApp is the dummy project with a dependency on the DataLibrary and targets.Provisioning.DataLibrary holds the DbContext with all of its models and targets.What they don’t clearly explain, is that you then need to do some extra steps to get the EF Core tooling (like migrations) working. The docs already indicate to create a dummy project with a dependency on the. Do note: I happen to still have the version ‘2.2.7’ of the EF Core tools installed, not sure how this behavior is with the newer versions. Next time I run into this issue, I should be able to find the solution quicker □. The documentation link does point you in the right direction, but it wasn’t as easy to find. ![]() For more information on using the EF Core Tools with. ![]() NET Framework that references this project, and set it as the startup project using -startup-project or, update this project to cross-target. NET Command-line Tools with this project, add an executable project targeting. There is no runtime associated with this framework, and projects targeting it cannot be executed directly. ![]() Startup project '' targets framework '.NETStandard'.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |