|
Hello !
I'm using vb.net 2013 , sql server 2008R2 , Entity framework 6 with DBContext database first.
when the user delete an object on an entity , I want to create a kind of "recovery script" and save it to a file. If this script is called by the user , he should recreate the deleted object again.
There are 2 cases :
- The record has no childs
- The record has childs ( so the recovery script should recreate the childs too)
I don't know if this will be a sql script , because when thi script will be used , the "Deleted object" should be inserted on an entity , and after should be the user that should decide to save it or no on database. Also before this object be saved on database , some testing actions will be made ( the same actions with the case when a new record is created )
any idea how can I do this ?
Thank you !
|
|
|
|
|
Holy crap this is over complicating things.
You've already been told how to do this. Just add a field to the root object that you can delete as "Deleted". That's it. No complicated "scripting", validation, reinserting, recreating child objects, blah, blah, blah.
One very simple operation undeletes an object and doesn't bloat the crap out of your database with "scripts" to recreate anything.
|
|
|
|
|
I have done what you have suggested.
So if a user do a "Soft" delete , I set the column to "deleted".
But the user can delete these "soft deleted records" , and on this case the record is deleted from database.
For this case I want to save a "Recovery script" ( similar to windows recycle bin. when a file is deleted from recycle bin too , a recovery process should be made if necessary to recover this file. ).
|
|
|
|
|
satc wrote: similar to windows recycle bin
That's the 'soft' delete flag being set. The hard delete is the same as when you empty the recycle bin, after which the file is really gone. However, if you want to recover them after that you just need to have another value that indicates hard delete.
|
|
|
|
|
What's happen if the files are deletes from "Recycle bin " ? The are gone ???!!! No. The can be recovered using Recovering software.
A similar behavior I want to do with records. When "a soft deleted record ") ( that has the "deleted" value=rue" ( is deleted , I want to have a way to recover. But keeping another field that indicate "hard" delete is not what I want. I want that a user to be able to really delete a record from database. And if he want he can recover ( just like on recycle bin for files.
|
|
|
|
|
satc wrote: The can be recovered using Recovering software.
Those files can not always be recovered; the space is marked as available, and could be (partially) overwritten. Still, you are comparing apples and oranges - the recovery software does not use a script.
Your users simply should not have the right to delete anything if they cannot be trusted with a recycle bin.
satc wrote: And if he want he can recover just like on recycle bin for files.
Then stop using a database completely and use the filesystem.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Quote: Then stop using a database completely and use the filesystem
Really ??
Please give me some idea how can I do this.
|
|
|
|
|
satc wrote: Please give me some idea how can I do this.
A databases stores it data different than the filesystem. That is why no major database-vender has an "undelete" functionality. If you don't want to throw it away, then don't throw it away - it is that simple.
And yes, it is simply a datastore; you can save all your stuff in old-fashioned text-files on the filesystem. That WILL support recovering the file, but will only work with complete FILES, not with a record in that file.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Will the entity Framework work with this "New way of storing data" that you have suggested ???!!!
I think no.
So better to return to the original question.
I have an object in entity framework that I want to permanently delete from database.
Is there an general way to store on a text file a script or something else that will help user to recreate this record if necessary ? ( of course not a sql script because I have clarify this on my first post ).
|
|
|
|
|
Wrong. That's what a database backup is for.
No, you don't do this in your code either. This is an operation left up to the DBA.
|
|
|
|
|
I've made the backup yesterday.
Today at 10AM I create a record.
At 11AM I delete this record.
after 2 days , I need this record.
could you please explain to me how can I use the backup to restore this record.
Thank you !
|
|
|
|
|
You don't.
You restore the entire database. Backups are a snapshot in time.
|
|
|
|
|
Oh , please.
I'm not talking for restoring the whole backup.
Please read what I want to do.
anyway , even with a entire backup restore , the problem that I've described above will not be resolved.
|
|
|
|
|
The reason you don't see this being done is because you've crossed into the point where the user is responsible for their own f*** ups and managing this becomes a nightmare!
Are you going to create restore scripts for EVERY record that is ever deleted?
How many tables can be restored? On my current application, I've got data going into 97 tables for ONE parent record.
How many records are going to be deleted in a month? For one record, in my case, that's a LOT of script to rewrite the record. How much disk space is going to be required to store all those scripts? More than the original data!
What scheme are you going to come up with to tombstone those restore scripts?
How are you going to re-write those scripts to support a new database schema? You really can't. Schema updates DO happen. I've done 9 schema updates in the last 6 months.
THESE ARE THE REASONS NOBODY DOES THIS!
If data that is "deleted" needs to be recovered. It's very simple. DON'T DELETE IT! Mark it deleted but never actually execute a DELETE command.
The only thing you need to do in your code is to make sure your queries don't return "deleted" data. Simple.
|
|
|
|
|
Quote: If data that is "deleted" needs to be recovered. It's very simple. DON'T DELETE IT
with this answer , I'm thinking why Microsoft has make this possible for deleted files. It's better to display a MessageBox when windows is open : " Users , please don't delete anything that needs to be recovered " 
|
|
|
|
|
Microsoft didn't make it possible. It's possible because of a side effect of how file systems work.
It's simple. You simply don't give the user the capability of deleting records.
Why do you insist on asking for advise and then ignoring everything everyone's tells you? What's been explained is how the pros do it and you've been told why. It's not that it's difficult to code. It's a bitch and a half to support it!
modified 28-Jun-15 16:37pm.
|
|
|
|
|
Then stop deleting it if you still need it later!
If you throw away a chair permanently, how would you go and restore it? Answer: once it is really gone, you can't.
You can "export" the data, say in a CSV format - but that would merely be "recreating" the data in another place.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Quote: If you throw away a chair permanently, how would you go and restore it? Answer: once it is really gone, you can't.
A chair is not composed by bites or bytes.
And why you are getting an example from material world. This is a more closer example : A file may gone from Recycle bin , but it can be recovered.
|
|
|
|
|
satc wrote: A file may gone from Recycle bin , but it can be recovered.
There's no guarantee that it can be recovered. It may be overwritten by the filesystem at any time and be completely gone.
Those bytes have to exist somewhere in order to recover them. Once they're gone, you cannot recover, regardless of the tools you use.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
There is not guarantee , but it's possible.
so let's get this possibility to the database users too.
|
|
|
|
|
satc wrote: so let's get this possibility to the database users too.
You go do that 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
You need to end your responsibility somewhere. You can't care for any and every eventuality. If you have a soft-delete then that is your recycle bin. Only "educated" users should be allowed to hard-delete soft-deleted entities and that should be the end of your/your software's responsibility. If something gets hard-deleted by accident then it's the user's fault and they will simply have to restore it manually.
If your client wants a second stage recovery then why doesn't he want a third stage recovery in case a recovery script gets deleted? It's BS. If you can't convince him of that, then rather implement a two-stage soft-delete than something like recovery scripts.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
The windows file systems has only 2 levels : 1) Add to recycle bin / Restore from recycle bin 2)Delete from recycle bin / Restore using recovery software.
So , I would like to add only 2 recovery stages.
But sorry , as we spend time discussing if this is/ or isn't good to implement , why someone doesn't give an idea ( if exists of course ) to implement this ?
|
|
|
|
|
satc wrote: So , I would like to add only 2 recovery stages.
A two-stage soft-delete would kind of be like that. Another idea would be to require confirmation for hard-deletion from a second user.
satc wrote: But sorry , as we spend time discussing if this is/ or isn't good to implement , why someone doesn't give an idea ( if exists of course ) to implement this ?
Because we deem it as best advice to discourage from doing that and probably no one here has done something like that yet.
A complication you probably haven't thought of yet: If your database schema changes your recovery scripts become incompatible. If I would be pressed to implement something like this I would have a second database with an identical schema where I would store the entities which were hard-deleted from the main database. If the schema should change, the same schema transformation could be applied to the second database.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Quote: no one here has done something like that yet.
Well for everything there's a first time , don't you think ?
I've thought the idea for a second database , but I think will be very complicated.For example :
Record1- has childs but also is a child for another table.
I delete record 1 and its child.
But to put this on the second database , I need the parent of record 1 too ( which is not deleted )....
So I think the idea to have a kind of script that could create only the deleted record would be more easy.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
