[metaltyphoon]

> I'm not really sure how you'd do a "cascading soft delete" without making some kind of manual cascading logic?

Perhaps the delete action is not accomplished right away and a column is checked. Then after a X amount of months a worker process goes around actually deleting things?

[ncmncm]

There is no need to delete anything at all. Set the "private" flag when the user asks for to make it private. Unset the "private" flag when they make it public again.

If it is needful to be able to delete stars, make a separate button for that. But it is hard to imagine such a need.

[mypalmike]

Stop. You've said the same thing a dozen times in this thread. Besides being repetitive, you're overlooking the obvious fact that having associations from non members of private repos to those repos is problematic. At the very least at the UI level, maintaining known dead internal links is bad form. So you'd be creating edge cases for the UI and probably numerous places deeper in the tech stack as well. Which is fine if you engineer solutions to all the edge cases. Perhaps after this incident they will consider doing so. But it's certainly not as trivial as you imply.

[fer]

Mmh? Maybe it's because I've never touched frontend professionally in my life, but I think that if you're doing it in the UI you're doing it VERY wrong.

This logic should be purely in the DB model or very close to it. In any case the internal API should never ever list private repos of an organization a user isn't a member of, period. Stars or no stars. Follows or no follows. Why should it? There's no corner case here, if stars pose a problem, the problem isn't the stars, it's a defective model behind. Hiding things that aren't meant to be seen in the UI means putting business logic in the UI. Just don't.

[mypalmike]

Fair point. My intent was to point out the UX would be broken. But you're right, the data model that backs that UX is what would have to change.

[brightball]

The complicated thing is that every query has to look for the column.

Ideally, moving the entire serialized record to an archive table keeps things as clean as possible.

[vaishnavsm]

I meant to focus on the cascade part of the equation here. For example, lets say `stars` are foreign keyed (FKed henceforth) to repos, and (say) `X` are FKed to `stars`, and `Y` is FKed to `X`. Then if you do a "hard" delete of the repo status (or the stars), then we can set that to cascade to `X` and `Y` as well. Otoh, I don't think you can apply a cascade like that automatically when you're just changing a value (which is how a soft delete would be implemented, ig). Can you? Is there some really cool hook that allows this?