I am looking into adding history tables to my database. The easiest way is to intercept all Insert, Update and Delete calls that EF Makes and add in a merge that will also insert a history row into a history table.
Right now all my Entities just let EF figure out how to do the inserts, updates and deletes.
If I go and add in stored procedures (instead of the EF Generated stuff) will EF still function the same on the business tier?
Or does it change how I have to work with my entities? If so, how?
Everything works the same, it is transparent.
Stored procedures need to return the rows affected, in order for EF to know that the update succeeded or not. Additionally, if you do an update and need to map any property back to your entity (e.g. timestamps) you must select them in the sproc and then map them back in the EF designer (since you can only have one output parameter, and that should be the rows affected).
You might consider using triggers on the DB to solve your issue, though?
Doing this in stored procedures means that you will write all inserts, updates and deletes yourselves. It is like throwing 30% of feature set (and 50% productivity) away. Create audit records in your application and save them together with main records through EF.
Related
I haven't written a single line with EF Core yet but I have been reading tutorials and trying to get a grasp of the concept first. I have not been abl to find any answers to these questions regarding losing data accidentally:
Using Database First, if I wrote the database model by hand and forget to add some tables as DbSet objects in the DbContext, are the missing tables DROP'ed on SaveChanges?
If a DbSet is left empty and SaveChanges is called, will all the rows in the corresponding table be DELETE'd?
In general are there any pitfalls that could lead to data loss by mistake or if you forget to do something, or do all hard delete actions require explicit code?
I have reformulated the questions a little, to avoid misunderstandings.
Are the tables that aren't in my DbContext dropped on SaveChanges?
The tables will only be deleted if you drop the database or otherwise delete the tables.
If a DbSet is empty and SaveChanges is called, will the rows of the corresponding table be deleted?
Yes. Otherwise the framework wouldn't work.
Are there any pitfalls that could lead to data loss by mistake or if you forget to do something
It depends on what you mean by mistake or forget to do something. If you forget to save your changes, then your changes will be lost. If you, by mistake, modify, delete or drop tables, then of course your data will be lost.
You should always backup your database regularly, test that the backup can be restored, and test new things on a copy of the database.
I have a web application using EntityFramework and an Azure SQL Database. I would like to know if deleting a row in the database removes the information permanently or simply marks is as deleted but it still be accessed if needed?
db.MyTable.Remove(objectInstance);
db.SaveChanges();
Is this someting that can be configured or do I need to implement this feature myself adding a deleted attribute?
The reason I want this is to be able to perform analytics including objects that might have been already deleted
EF has nothing to do with this actually. Whether records are deleted permanently or not is actually up to the RDBMS. EF is an ORM for the RDBMS.
Options IMO:
You manage the records marked as deleted using an extra column
You can move the deleted records to another table or file whichever is convenient for you to run analytics on. That way your queries will have to touch less number of records and be faster.
You can go through the log files and execute the INSERTs again to get the deleted records.
Hope my suggestions help you in right direction.
I am working on my first project using an ORM (currently using Entiry Framework, although that's not set in stone) and am unsure what is the best practice when I need to add or subtract a given amount from a database field, when I am not interested in the new value and I know the field in question is frequently updated, so concurrency conflicts are a concern.
For example, in a retail system where I am recording a sale, as well as creating records for the sale and each of the line items, I need to update the quantity on hand of the items sold. It seems unnecessary to query the database for the existing quantity on hand, just so that I can populate the entity model before saving the updated quantity - and in the time taken for that round-trip, there is a chance that the same item will have been sold through another checkout or the website, so I either have a conflict or (if using a transaction) the other sale is blocked until I complete my update.
In SQL I would simply write
UPDATE Item SET Quantity=Quantity-1 WHERE ...
It seems the best option in this case is to fall back to ADO.NET + stored procedure for this one update, but is there a better way within Entity Framework?
You're right. ORMs are specialized in tracking changes to each individual entity, and applying those changes to the DB individually. Some ORMs support sending thechanges in btaches, but, even so, to modify all the records in a table implies reading them all, modifyng each one, and sending the changes back to the DB as individual UPDATEs.
And that's a big no-no! as you have corectly thought. It implies loading all the rows into memory, modifying all of them, track their changes, and send them back to the DB as indivudal updates, which is way more expensive that running a single UPDATE on the DB.
As to the final question, to run a SQL command you don't need to use traditional ADO.NET. You can run SQL queries directly from an EF DbContext using ExecuteSqlCommand like this:
MyDbContext.Database.ExecuteSqlCommand('Your SQL here!!');
I recommend you to look at the MSDN docs for Database class, to learn all the things that can be done, for example managing transactions, executing commands that return no data (as the previous example) or executing queries that return data, and even mapping them to entities (classes) in your model: SqlQuery().
So you can run SQL commands and queries without using a different technology.
I have multiple processes accessing the same database table. The table holds "TakenBy" column that is supposed to hold the ID of the taker process.
Entity Framework is my data access layer.
My question would be how can I use my DataContext object so I can retrieve rows from the above table, and have the "TakenBy" column updated at the same time.
This would allow me to overcome race-condition with the other processes, who also try to get the same records.
EF will not handle that for you. You must either use stored procedure or you must perform update once you load the record through your application and handle concurrency (either by optimistic way which means to use times tamp or row version column or by pessimistic way which means manual SQL query).
I have multiple string values, I want to insert in an sql server db table, But i want to check values one by one if it already exist in the db I will update, if not I will insert it.
I am using Entity Framework 4.1, and I hope I can do that with best performance, means less calls to db as I can.
I saw this question before, but they are using linq to sql not entity framework.
One way you could do it is to batch up the queries for existence ... for example, using the .Contains method (like this), you can query for some or all of the items which may or may not exist at once. Then once you have the data locally, you can quickly check if it's there before inserting