Does this migration have to be done when diaspora* is stopped?
We got feedback on the forum, thatās nice. It looks like weāre now releasing too big releases to have a generic āUpdatingā page on the wiki. A specific guide with every steps in the right order for each release looks more appropriate. I donāt know if this should be directly in the changelog or on the wiki.
Hmm, the steps are given in the changelog when needed. It would seem unnecessary to repeat them in the wiki, and also make that page harder to follow, because youād have to find the relevant instructions for the version you want to update to. And it might lead to people doing manual steps when updating to a version which doesnāt require them.
How about a general note: āWhen updating to a major version (0.x.0.0) you may need to perform some manual steps, for instance a database migration, before updating the app code. Please check the notes at the head of the changelog for the version you are updating to before starting to update.ā
(Could prob word this betterā¦)
How about a general note: āWhen updating to a major version (0.x.0.0) you may need to perform some manual steps, for instance a database migration, before updating the app code. Please check the notes at the head of the changelog for the version you are updating to before starting to update.ā
We already do that, the problem is that the different manual action are not in a specific order. Youāll understand what Iām saying reading https://diasporaforum.org/t/my-0-5-0-0-rc-feedback/312
Does this migration have to be done when diaspora* is stopped?
Well, not a DB expert, but Iām willing to bet yes.
But another question worth asking is, is this migration necessary. @dumitruursu ? @jhass ? You are the guys who worked on these. Iām assuming at least that the migration takes time doing the shorten_indexes part (https://github.com/diaspora/diaspora/blob/develop/db/migrate/20150106050733_set_mysql_to_unicode_mb4.rb#L48).
Yes, it is necessary.
Yes, it is necessary.
Sorry - Iāll rephrase. Is the shorten_indexes part necessary? 
Yes, at least on MySQL it is. And I really donāt want to let the schema diverge that much between MySQL and PostgreSQL pods. Besides it runs faster on PostgreSQL anyways.
You guys have seen how long migration took on a small 1.6GB db, right?
Any feedback from ppl running >20GB dbs yet?
And I really donāt want to let the schema diverge that much between MySQL and PostgreSQL pods.
Yes, that is a valid point. Reading into index length Iām not really just sure why we set it. It certainly doesnāt seem like a required thing to have. But then, the shorten_indexes seems to do many other changes too, at least looking at the schema.rb, so I guess picking it out as an optional step would be trickyā¦
Would be nice to have more pods report feedback.
@dennisschubert ran the migration on a ~50GB database, and it took 1 hour 31 minutes. We made some tradeoffs with @jhass, and this is the best we could do. Given the state of MySQL utf8 support, I would drop it altogether, butā¦meh, I know we canāt do that.
One solution is to use another engine for MySQL(innoDB), but required changes with administrative privileges, and many podmins might not have that.
Weāre already using InnoDB, at least my database does. So I doubt this makes any difference.
I am wondering if it is actually needed to modify each column on its own? I always thought an ALTER TABLE also affects the columns in it?
Edit: Just for the record, everything is blazingly fast without the column-loop: https://gist.github.com/denschub/dd4c23c3b83b343378e8#file-without_columns
But that makes me wonderā¦ I donāt think it does a conversion at all since it is way too fastā¦
@dennisschubert, innoDB on itās own doesnāt do much. But using the large indexes option, and another trick that I forgot, you can increase the index size, which would make the whole index trimming process redundant.
So, what are the next steps to making v0.5.0.0 a reality?
Sweet 
Only three left now! #exciting
I got rid of one of them, yay!