Thing is, this is what happens to you if you complain at Flickr. They don't like having to actually do work. That's pretty obvious from the fact that after over five years of losing people's photos like this, they still fail to back up anything. The founder even lost all his stuff at that cluster-f of a social network gone wrong. What's funny about those slackers at Yahoo's Flickr is that they think they can pull off hosting a porn site, while pretending it's a family friendly place for your kids' photos. That may be fine for the average user that wacks off at work, but not so good for an advertising platform, as it turns out. You see, major corporations and small businesses alike have an issue with their ads being surreptitiously placed onto hardcore pornographic web pages without being told about that. Yahoo's Flickr can play this game of hide-the-porn while tricking the general public into trusting them. But those lies don't really fly in the advertising world on which Yahoo depends. Everyday, several people get deleted from Yahoo's Flickr as that company desperately attempts to make their porn site not really appear to be one on the surface. The copyright infringement is the same thing on a smaller scale. They count on people stealing your content, that's why they tricked you into placing it all online in an easily accessible catalog of stock images from trusting idiots. Make any kind complaint about the way they are doing anything, and you're booted out mercilessly. That's just the way it goes and Yahoo doesn't care one bit how you feel, because they obviously do whatever they want to. They have the government in their pocket and free reign to push porn into grade schools unlabeled, give your photos away for free to anyone that wants them without liability, and harbor countless sexual predators, pedophiles, and registered sex offenders, whom they cloak so they can be right next to your children without anyone being suspicious. Can't really see anything worthwhile about that website, or Yahoo in general. It's all lies from them, and everyone eats it up with a clueless smile.
Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back
91–93 of 93 posts
Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back
#92Earlier quoted context omitted.
> You never actually delete rows from your tables. You mark them as deleted, sure, but the data needs to be able to come back. Space is cheap, there are simply very few cases where outright deletion from a DB table is warranted. This comes with a cost, and it's not a small one. Every single query that ever touches this table, in every single piece of code owned by the company, written or maintained by every single de…
No, that's what views are for. A sane approach would be to do all your table access via views, and the view definitions have the 'where is_deleted = 0' or whatever. Then your database handles it. Updates to the view work as well, in pretty much every database system, including MySQL even.
That just shifts the problem. Every piece of code and every developer now needs to know to hit that view rather than directly hit the table. Except the code that actually deals with deleting and undeleting which has to hit the table directly (or another view or sp.) And you still have the original problem in writing and managing the views themselves - every developer writing or maintaining one of those views needs to know to respect "where is_deleted = 0".
Using views adds a layer of abstraction. That's often a good idea and a step in the right direction, but does come at the cost of increasing the overall complexity of the system. It's an incremental step to the positive, but no revolutionary solution.
Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back
#93This is why I never have a DELETE call anywhere in my app or admin code. I always mark as deleted (there are performance improvements in this for some databases as well)
I've worked at several places where the strategy is 'never delete, just mark as deleted'. Your database tends to grow pretty fast, but you never have to defragment your index or tablespace.
I usually setup purge tasks (copy to same table in another db) every week or fortnight in low-traffic periods