Repository navigation
Proposals migration script - #2166
ArtOfCode- wants to merge 1 commit into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files
☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
I notice that reactions will be deleted. In the case of Puzzles, the "Works for me" reaction is often used by the puzzle author to indicate an answer is a valid solution to the puzzle. If moving reactions will be impractical, it will be possible for the puzzle authors to go through all their puzzles and manually add these again, but Will in particular has a non-trivial number of puzzles (I just checked: Will alone has 69 puzzles, 61 of which have answers, a total of 90 answers just to Will's puzzles, to manually assess for validity if reactions are not migrated). |
|
For a new community which will have more categories than just Q&A and Meta, is the intention to move everything into the standard Q&A and Meta first, and then have a moderator/admin set up new categories and migrate posts? For Puzzles this would be feasible since there is only 1 post for the Q&A category, with all the rest of the non-Meta posts going to a Puzzles category. Rather than move all but 1 of the questions, could the Q&A category created by this script be renamed by a mod afterwards to Puzzles, and then a new Q&A category be created to have its 1 question moved to? If renaming a category would be problematic, could this script be modified just for Puzzles to create a Puzzles category rather than a Q&A category (or in addition to a Q&A category if that is easier)? Then having the script put all the non-Meta posts in the Puzzles category would mean only 1 question to be manually migrated to the Q&A category. |
I debated about this, along with flags. Ultimately the reason I decided this way is the same reason we're not bringing closed questions across - reaction types, flag types, and close reasons are community-specific, so we can't just move content that refers to one of them without changing the relevant reference ID to a new reference for the newly-created community. For instance, "works for me" might be ID 123 on Proposals, but once we create a new community and its reactions, "works for me" there might be ID 456. It's not impossible, but I couldn't easily find an efficient way to do it in SQL and I'd rather not fragment the migration across SQL and Ruby. Open to discussion or other ideas of how to do this efficiently. |
Essentially yes, but we can specify which category to move them into (that's the |
Ah, I see the problem now. Double the problem since I'm guessing reactions are per category, and Puzzles has a fair bit of usage of "Works for me" across both Q&A and Meta. Would a reasonable approach be to take a record of the relevant reactions data before migration (since there will presumably be no trace of it left in Proposals afterwards?), and then once the migration is confirmed successful the data will be available for a potential (non-essential) extra job? |
|
Longer term, I can imagine a robust way to migrate reactions being useful, if communities are proposed that make greater use of them. I take it there is no upper limit on number of reaction types per category? If a proposed community wants to test out reactions, could they add reactions that only make sense for their community with a prefix to let other proposals know not to use them? Perhaps: "Dragoncraft proposal only: Only applies in winter" |
|
Should this PR be in the Because this is specific to our deployment, we can control some of the unknowns. Our Proposals site does not use non-standard reactions in the incubator (it does for descriptions, but we don't care about those). I'd like to have the reactions survive the migration, but that could be an export and an import rather than a SQL UPDATE if that works better. Reminder: your reactions don't show up in your profile, so a user has no way to find them other than brute force, and in the case of this migration brute force wouldn't work (they'd be gone). Can we do something like: export all uses of the standard three reactions in the incubator and meta, set up the new community, get the IDs of the corresponding reactions on the new community, and import the export file rewriting the IDs? As for categories, for this pass it's fine to put all incubator posts in one category and sort it out on the other end. We've talked about using tags to indicate target categories (for worldbuilding), and in the future, if we have a multi-category proposal launch, we could update to use that info. It's not something we need to bite off now. |
| WHERE | ||
| pt.post_id IN (SELECT post_id FROM all_posts) | ||
| AND t.tag_set_id = @proposal_meta_tag_set | ||
| AND t.id != @proposal_tag_id; |
There was a problem hiding this comment.
And I guess these will need to find those tag IDs from the new meta. I'm not sure how to do this cleanly.
There was a problem hiding this comment.
If I understand the following correctly:
SET pt.tag_id = (SELECT id FROM tags WHERE `name` = pt.`name` AND tag_set_id = @proposal_meta_tag_set)This is changing the tag_id for each tag on a migrated meta post to be the id of the new meta tag that has the same name as the old meta tag in Proposals?
So a migrated meta post will show the same tag names as before, despite the tag_ids being different?
If that's the case, would a similar approach work for the reactions, since the reaction names are just the default ones?
There was a problem hiding this comment.
I'm hoping that's what it does - haven't had the chance to test it yet. Two considerations with that:
- If we want different names for the reactions, this fails. For instance, I've created Puzzles with a "correct answer" reaction instead of "works for me", which this won't find.
- I can't imagine this approach is at all efficient.
There was a problem hiding this comment.
I guess mapping to a different reaction name would require some hardcoding (although maybe that would also improve efficiency...).
How important is efficiency for a one off script run on a few hundred items? Is the time taken for the script time during which all communities will be down (rather than just Proposals and Puzzles)? How much down time would be acceptable?
There was a problem hiding this comment.
If the downtime cost is too high, how about exporting reactions, doing the migration, replacing the reaction IDs in the exported data, and importing it? It's ok if reactions lag the posts, but I'd really rather not lose them and or make users re-apply them by hand.
There was a problem hiding this comment.
I like that idea. If there's any concern about the data drifting due to user activity in the time between the migration and the import, I guess the Puzzles categories could be locked (by restricting to mods only if there isn't a direct way). This way the downtime is only for the community that is getting something out of it.
| SELECT pp.id | ||
| FROM posts pp | ||
| INNER JOIN posts_tags pt ON pp.id = pt.post_id | ||
| WHERE | ||
| pp.community_id = @proposals_community_id AND | ||
| pt.tag_id = @proposal_tag_id |
There was a problem hiding this comment.
I believe it should be safe and more efficient to use the temp table's state from the previous table for the parent_id subquery. We only want to pick up posts whose parents are fetched in step one anyway, right?
4 participants
Add SQL script for community migrations from Proposals. First draft - comments sought!