Email or username:

Password:

Forgot your password?
dansup

I'm starting to notice some bad decisions I made regarding @pixelfed database structure

In 2018 when I first started Pixelfed, I took a lot of inspiration from Mastodon, and while their DB structure makes sense for them, I'm realizing that it's starting to limit us

Storing posts, replies, and shares in a single table doesn't make sense for us

Fixing this will be fun, I love challenges and look forward to blogging about it after a seamless deployment.

The goal is to make this unnoticeable 😎

8 comments
dansup

@sirber @pixelfed [statuses] [status_replies] [status_shares] basically moving the replies (in_reply_to_id) and reblogs (reblog_of_id) into their own tables

Captain Steph

@dansup @pixelfed smaller tables is generally good, index wise

wikiyu

@dansup @pixelfed

Years ago when i was younger i would suggest "procedure" approach -> move all DB stuff to as encapsulated procedures as possible (crud)

then making a migration BUT with stay on application side to procedures that are changed with migration.

Now? I dont know, i didnt thought about stuff like that for at least 4? 5? years as i am doing a bit different part of it development now then then.

dansup

@wikiyu @pixelfed Well, we do use Laravel, so we can make versioned migrations but this is a bit more complex than a simple migration.

Data needs to be slowly synced to prevent downtime

wikiyu

@dansup @pixelfed

Do you really need "no downtime"?

I think that stuff like that doesnt have to be done seamless...

More important is stability and being sure of doing it right, then "no downtime"

Henri

@dansup I think this is just copying the Twitter concept of a tweet?

kcarruthers

@dansup data architecture is often a gotcha. Good luck.

Go Up