📈 Similar Worlds #️⃣ pages Indexed, UP 3x since Group Consolidation 🚀

@PirateMonkeyCabinet This is a must ... it is taking me forever to copy my content and delete

@questionWeaver An export button would probably be nice too I suppose.

@PirateMonkeyCabinet
I’d be very happy to use this feature. I don’t know if their limit for deletion is every 24hrs… it would take me awhile to manually delete all my content.

@CookieCrumbs No one seems to know the actual conditions... at least no one I've come across. Don't think staff has shared those either.

What I've heard from others though means it is a complicated, multi-stage cooldown. Don't know the exact details, but some have said that attempting to delete something before it is done with the first stage of cooldown resets the timer to.

Saw someone mention deleting 20 posts within an hour I think before cooldown came into effect. I believe there is still an extra layer of cooldown outside of that too. It's just... needlessly complicated to get rid of your stuff.

I can't vouch for any of that info either.

@PirateMonkeyCabinet these feature requests have been noted, and are in considerations for scheduled development.

There are some challenges relating to "Mass Deletion", or any "Mass Actions" as a matter of fact,
which is also a factor in why there is a Limit in terms of how fast/often someone can Post, Comment, Heart/React, etc.. (apart from anti-spam measures).


[b]1) Mass Deleting puts strain on operating servers.[/b]

Each time a Post is "Deleted", it isn't a singular action. A series of events need to unfold on the servers, one after the other.

There are lots of interlinking values associated with each posts, not only the actual content.

There are also internal values on:
- Subscribed users, and the various levels of subscription.
- Users who Blocked or Muted the post
- Report History
- Post Edit/changes data
- Views data
... and so on.

All of these values need to be broken/changed on various parts of the server database, as it relates to different users and groups.

Allowing a "Batch Operation", such as "Mass Deletion", can potentially overwhelm system resources, and cause performance issues for the rest of the site.



[b]2) Deleting content, takes more Work/Processing than creating the same content would.[/b]

This is true in generally most cases (if not all).
This is because, from the moment a post or comment is created, more and more interlinking values/data becomes attached to that piece of content.

A new post, doesn't have much attached links or data.

An existing post, would have many associated values, such as:
- Subscriptions, Reports, Blocked, Views, etc...

Therefore, there is more work/processing involved, in deleting posts vs creating them,
yet still, we have the same limits in place to prevent users from "Mass Creating" posts/content.



[b]3) A large % of deleting users, ask for their content to be restored.[/b]

Many times, a user may wish to delete content based on a short-term event or scare,
and may change their minds, afterwards wish to have that content back.

The existing "Speed Limit" of Deleting posts, also greatly reduces these types of requests, as it gives users more time to reconsider, what it is they really want, in the end.

@Andrew I understand that far from everyone here has the technical knowledge to understand how things work without a detailed breakdown, so hopefully that explanation you made will make sense to them.

That said, I'm well aware of the complexities related to many-to-many relationships as you describe. There are certainly considerations to make. As you say, the more interactions a post has had (be it comments or reactions) it has more links that need to be resolved properly. More links means more operations, more operations generally means more processing power used.

[sep]

But okay, you say you're listening to users, so let's have a constructive discussion about this instead of just the constant explanations of why we don't get it or get how complicated things are. Instead of looking at explaining stuff away, let's discuss solutions instead.

Now let me preface this by saying databases has never been my primary field, so forgive me if my terminology is rusty or somewhat incorrect at times.

[sep]

So my thoughts on this:

When attempting to delete a post some may get the option of hiding it instead of deleting it. Would it be reasonable to assume this is stored as a boolean or some equivalent to an enum? While it obviously still requires a fair share of processing power to handle a lot of posts at once, such operations are surely a lot cheaper than going through all links to break them at both sides.

So why not turn larger deletion batch jobs into a multi-stage process? Since hiding is cheaper than deleting, start by hiding posts at a reasonable rate. This should take the posts out of public circulation. Once that is done, then you start the deletion process. Since the posts are hidden by that point a user should be able to rest assured that the posts are not visible anymore and as such the deletion process can be done at a pace tailored to server load.

Put a little notice on a users profile (only visible to user) that shows the progress of the batch deletion job (if it'll save cycles, maybe only update on refresh and only show changes once every certain amount of seconds/minutes). Only allow a user one active batch job at a time, but where each job can have a high amount of posts or comments). Include a notice when requesting deletion that it will happen in two stages to prevent overloading the servers, and that they can view the progress on their profile.

[sep]

As for the whole thing about users regretting it, yep, can understand that it happens. I will admit I don't have as much of a suggestion for that as for the technical side.

That being said, what about those who won't regret it? Those who know very well that they want or need it done? They are stuck with an unreasonable job ahead of them that, depending on how much they've posted, can take everything from a day to weeks or more just to delete their stuff. There [i]needs[/i] to be a better solution for these people too.