Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab FOSS GitLab FOSS
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 0
    • Merge requests 0
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLab FOSSGitLab FOSS
  • Merge requests
  • !5670
The source project of this merge request has been removed.

Add a data migration to fix some missing timestamps in the members table (again)

Merged Nick Thomas requested to merge (removed):20568-fix-member-data-again into master Aug 04, 2016
  • Overview 5
  • Changes 2

What does this MR do?

Repeats an earlier migration to fix historic bad data in the members table (missing created_at and updated_at fields)

Are there points in the code the reviewer needs to double check?

I'm expecting the WHERE clauses to be fast enough, and to return few enough rows, that the migration doesn't need to use batches, but I'm not too familiar with the size of these tables in the wild, so perhaps that's a poor assumption.

Why was this MR needed?

8.10 introduced a dependency on the members.created_at field in the project and namespace member view. If bad data is present, viewing the list of members now results in an NoMethodError and a 500 response from GitLab. Although the previous migration should have fixed all bad rows, we have evidence that it didn't in at least one case, despite the migration claiming to have run in the past.

What are the relevant issue numbers?

#20568 (closed)

Screenshots (if relevant)

Does this MR meet the acceptance criteria?

  • CHANGELOG entry added
  • Documentation created/updated
  • API support added
  • Tests
    • Added for this feature/bug
    • All builds are passing
  • Conform by the style guides
  • Branch has no merge conflicts with master (if you do - rebase it please)
  • Squashed related commits together

Closes #20568 (closed)

Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: 20568-fix-member-data-again