Diaspora* software release


(Flaburgan) #41

Does this migration have to be done when diaspora* is stopped?


(Flaburgan) #42

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.


(goob) #43

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…)


(Flaburgan) #44

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


(Jason Robinson) #45

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).


(Jonne Haß) #46

Yes, it is necessary.


(Jason Robinson) #47

Yes, it is necessary.

Sorry - I’ll rephrase. Is the shorten_indexes part necessary? :slight_smile:


(Jonne Haß) #48

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.


([deactivated account]) #49

You guys have seen how long migration took on a small 1.6GB db, right?

Any feedback from ppl running >20GB dbs yet?


(Jason Robinson) #50

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.


(Dumitru Ursu) #51

@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.


(Dennis Schubert) #52

We’re already using InnoDB, at least my database does. So I doubt this makes any difference.


(Dennis Schubert) #53

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…


(Dumitru Ursu) #54

@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.


([deactivated account]) #55

So, what are the next steps to making v0.5.0.0 a reality?


(Jonne Haß) #56

Cleaning out the milestone: https://github.com/diaspora/diaspora/milestones/0.5.0.0


([deactivated account]) #57

Sweet :+1:


([deactivated account]) #58

Only three left now! #exciting :slight_smile:


(goob) #59

I got rid of one of them, yay!


([deactivated account]) #60

Nice one @goob

Now stalled on three it would seem…