3 ms·

So mark the repo as private without their permission to view and have queries for starred repositories ignore repositories you can't view - that's an extremely

by munk-a 5y ago

So mark the repo as private without their permission to view and have queries for starred repositories ignore repositories you can't view - that's an extremely frequent approach to take with complex permission and social functions. I completely understand that not everyone has time to build everything and software is an evolving process - but soft deletion for social links is my default state of mind (then you overlay it with indexing or caching or whatever your performance flavor is to make sure those soft deleted rows don't exist in the active query space).

akerl_ 5y ago
I mean, they totally could have built it that way. But they didn’t. I was answering why stars were removed. From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars. The downside is the behavior seen when a repo goes private, but my bet is that repositories being made private is far less frequent than calls to get a list of starred repos.
- munk-a 5y ago
  I totally get that - it's not an insane design decision it's just different from what my default suggestion would be. And to be honest - your source of truth database, on a system of this scale, is likely going to be detached from your pool of active data (possibly with some data shadowing, caching - what have you). The thing that throws me off is that they shot themselves with this footgun - whenever we (munk-a's employer) footgun ourselves we remove the footgun to prevent future footgunnery. They made the original design decision one way, and when they were burned by it they didn't re-examine it.
  - akerl_ 5y ago
    FWIW, if the blog post had centered around “GitHub, it’s strange to me that you made this mistake and didn’t reevaluate the root causes, and now I’ve made the mistake and it sucks”, I’d not be griping all over the comments here. It’s the framing that GitHub has inflicted a deep, irreparable wound to the author that I can’t reconcile with the facts.
- Dylan16807 5y ago
  > From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars. You can also solve that by adding a flag column, or putting privated stars in a different table. That tiny bit of denormalization shouldn't be more expensive than the current process, or the other costs of privating/unprivating a repo.

by munk-a 5y ago

akerl_ 5y ago

I mean, they totally could have built it that way. But they didn’t. I was answering why stars were removed. From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars. The downside is the behavior seen when a repo goes private, but my bet is that repositories being made private is far less frequent than calls to get a list of starred repos.

munk-a 5y ago
I totally get that - it's not an insane design decision it's just different from what my default suggestion would be. And to be honest - your source of truth database, on a system of this scale, is likely going to be detached from your pool of active data (possibly with some data shadowing, caching - what have you). The thing that throws me off is that they shot themselves with this footgun - whenever we (munk-a's employer) footgun ourselves we remove the footgun to prevent future footgunnery. They made the original design decision one way, and when they were burned by it they didn't re-examine it.
- akerl_ 5y ago
  FWIW, if the blog post had centered around “GitHub, it’s strange to me that you made this mistake and didn’t reevaluate the root causes, and now I’ve made the mistake and it sucks”, I’d not be griping all over the comments here. It’s the framing that GitHub has inflicted a deep, irreparable wound to the author that I can’t reconcile with the facts.
Dylan16807 5y ago
> From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars. You can also solve that by adding a flag column, or putting privated stars in a different table. That tiny bit of denormalization shouldn't be more expensive than the current process, or the other costs of privating/unprivating a repo.