Slightly related: is Bluesky moderated good enough or do I get lots of rightwing and conspiracy crap like on twitter currently?
I‘d really love to have some more civilized hub again that isn’t full of hate and anti-intellectualism.
Bluesky migrates to single-tenant SQLite
131–140 of 247 posts
Re: Bluesky migrates to single-tenant SQLite
#132Slightly related: is Bluesky moderated good enough or do I get lots of rightwing and conspiracy crap like on twitter currently? I‘d really love to have some more civilized hub again that isn’t full of hate and anti-intellectualism.
I think it is still too small and people seem quite nice there. But, that has its drawbacks, as I keep returning to Twitter due to the slow migration in the recent months.
It is a shame, as it seems like a nice alternative that has some cool ideas.
Re: Bluesky migrates to single-tenant SQLite
#133Earlier quoted context omitted.
bsky-social-lbjkg-gcxs4 bsky-social-zigwm-f3qpq bsky-social-2jlu7-apy5a bsky-social-6ct52-4egmz bsky-social-cy64m-53sqn
Maybe if you stop posting them with the easily-greppable first part they won't be so easy to scrape.
No one seems to be taking two codes I'm putting up without the prefix for ~hour, this is likely the case
e: second one now used, first still up
e: both used
Re: Bluesky migrates to single-tenant SQLite
#134Earlier quoted context omitted.
Commit your code and commit it often. There's no reason not to.
Sure, but then there's nothing wrong with rebasing it and making a nicer story for other people that want to review it. Diffs are great but sometimes they're just as overwhelming in a huge PR. It's nice to first follow 5-10 commits in chunks of logical change.
I don't know why people are obsessed with squash merging. I always rebase (when needed) to preserve commit history. It's a good best practice, and makes it easier to spot errors after fixing conflicts.
I suspect squashers use the wrong tools. Use source tree, or, if you are on linux, smartgit. You can see a detailed log, which makes it much easier.
Re: Bluesky migrates to single-tenant SQLite
#135Re: Bluesky migrates to single-tenant SQLite
#136Love SQLite - in general there are many challenges with a schema or database per tenant setup of any kind though. Consider the luxury of row-level security in a shared instance where your migration either works or rolls back. Not now! If you are doing a data migration and failed to account for some unexpected data, now you have people on different schema versions until you figure it out. Now, yes, if you are at shard…
> The funny thing is that about a decade ago, the app was born on a SQLite per tenant setup, then it moved to schema per tenant on Postgres, now it's finally moving to a single schema with RLS.
To be fair, RLS was not available yet a decade ago :) It appeared in PostgreSQL 9.5 in 2016.
Re: Bluesky migrates to single-tenant SQLite
#137Earlier quoted context omitted.
I prefer to read the unified diff and commits don't matter as much.
Commit your code and commit it often. There's no reason not to.
Sure, commit often while you're working.
But then when you're done, turn it into a series of patches for a reviewer to read. In the words of Greg Kroah-Hartman, "pretend I'm your math teacher and show your working".
In a maths assignment, you spend ages making a big mess on a scrap of paper. Then when you've got the solution, you list the steps nice and clearly for the teacher as if you got it right first time. In software development, if you're not a dick, you do the same. You make a big old mess with loads of commits, then when you're done and it's review time, you turn it into a series of tidy commits that are easy for someone to review one-by-one.
Re: Bluesky migrates to single-tenant SQLite
#138Earlier quoted context omitted.
Maybe if you stop posting them with the easily-greppable first part they won't be so easy to scrape.
No one seems to be taking two codes I'm putting up without the prefix for ~hour, this is likely the case e: second one now used, first still up e: both used
I wonder what they're being used for. The UI doesn't expose it, but the Bluesky API will tell you who redeemed your invites. Open the site, watch for a "com.atproto.server.getAccountInviteCodes" request in your browser's network inspector, look in the "usedBy" field in the response JSON, and append the DID value there onto "https://bsky.app/profile/". Any commenters in the parent chain who got scraped want to take a look?
Re: Bluesky migrates to single-tenant SQLite
#139Can someone that knows more about bluesky explain what data is stored in sqlite and not? Because i assume it isnt messages etc between users.
I assume that messages between users are stored in those SQLite DBs.
Think email. When you send an email and CC five other people as well then seven people now have the same copy of the email stored on their email servers. That is, there’s no central database that contains a single email that is referenced by others.
This is basically how sharding with relational DBs works as well.
This sort of data denormalization is almost a requirement as applications scale and especially for many-to-many applications that have a high write to read ratio.
Low write to read and you can get away with a single master to many slave relational DB architecture for quite astonishing numbers of requests and data!