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.
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 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 am SysAdmin for a couple of large online shops and I'm researching Memcached as a possible caching solution.
The most accessed queries are the ones which make up the dynamic product pages, so it would make sense to cache these. Staff regularly use an update program to update the tables with new prices. As I understand, if I used Memcached the changes would only be apparent after the cache expires and not after my program has updated.
In the docs, I can see "Memcache::flush" which flushes ALL existing items, but is there a way to flush an individual object?
You can see in docs that there is delete command that removes one item. Also there is a set to add or replace one item.
The most important part is to have a solid naming scheme on your keys. Presumably you have a cms type page to update/insert rows in your database (mysql?). Just ensure that you delete the memcache record whenever you do an update in mysql and you'll be fine.
I am using Self Tracking Entities with the Entity Framework 4. I have 2 databases, with the exact same schema. However, tables in one database will be added to/edited etc (and I mean data will be added/edited, not the actual table definitions) and at certain points of the day I will need to synchronize all the changes between this database and the other database.
I can create a separate context for both of them. But if I read a large graph from one database, how can I update the other database with the graph? Is there an easy way?
My database model is large and complex and fully relational. So it would be a big job to go through every single entity and do a read from the other database to see if it exists or not, update/insert it if need be, and then carry this on through the full object graph!
Any ideas?
This is not a use case for EF. In EF you will have to do exactly what you've described. Self tracking entities are able to track changes to these object instances - they know nothing about changes made to their own database over time and they will not know anything about state of your second database as well.
Try to look at SQL server native features (including mirroring, transaction log shipping or SSIS) and MS Sync framework. Depending on your detailed requirements these tools can suite you better.
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.