|
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.
|
|
|
|
|
satc wrote: Well for everything there's a first time , don't you think ?
Sure. But there's a reason why there's no "standard procedure" for this. Because it's a mess, regardless how you approach it. The day will come you regret you opened this can instead of telling your client not to hard-delete a record if he wants to be able to recover it or to leave it up to the DBA 
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
So :
" A problem difficult to resolve" = " It's better to not implement this" 
If the restoring is a useless feature , so maybe we can tell Microsoft to remove from file system too.
|
|
|
|
|
satc wrote: So :
" A problem difficult to resolve" = " It's better to not implement this"
Why attempt to implement in code something that
- is very complicated and prone to be buggy or to break with changes
- is likely to be used only very rarely
- can be solved in a different way* much easier ?
*: Through backups / DBA. If you want to care for the case that a record gets deleted before a database backup has run then simply disallow hard-deletion on the same day.
satc wrote: If the restoring is a useless feature , so maybe we can tell Microsoft to remove from file system too.
Restoring after emptying the recycle bin isn't guaranteed to succeed - it's likely that parts of the file have already been overwritten.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
A database is not a filesystem, and no, it would not be very wise to start depending on a blob that "may or may not be" overwritten and hence, may or may not be recoverable.
satc wrote: " A problem difficult to resolve" = " It's better to not implement this"
I'm looking forward to your article on how you solved it
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: I'm looking forward to your article on how you solved it
Indeed
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Well , I try it to resolve after getting a final word from you like this : " On my opinion there's no way to do this" . Can you claim this ?
|
|
|
|
|
As I tried to communicate with my previous replies, it's not impossible but far from economical.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
satc wrote: I try it to resolve after getting a final word from you
You already had it several times, and I will think twice before getting involved again
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
