[6.1] Issues renumbering
Closed
[6.1] Issues renumbering
Created by: sashkab
With 6.1 update I was surprised, that GitLab decided to brake everything and introduce project-related ids for issues, merge requests. This broke a lot of things:
- comments in commits mention old issue numbers;
- issues mention old issue numbers, but they weren't translated to new id;
- same thing with merge requests.
From one point of view, global IDs where issue. From other, when performing upgrades, GitLab could have kept old issue/merge ids for existing projects. I don't understand, why you couldn't have kept IDs same, despite making them project related?
I «fixed» this with UPDATE issues SET iid=id;. Seems to work for me, but will this cause any issues, I'm not aware of? I didn't have to update merge_requests table, but it can be updated same way: UPDATE merge_requests SET iid=id;
Why brake what's working?
Created by: hiroponz
Written on http://blog.gitlab.org/gitlab-community-edition-6-dot-1-released/. So updating iid may cause some problem.
Issue and Merge Request ID’s start at 1 for each Project
The ID’s for Issues and Merge Requests now start at 1 for each Project. This means that bookmarked issue URL’s will > change. Old issue URL’s are redirected to the new one if the issue ID is too high for an internal ID.
By Administrator on 2013-09-25T14:47:30 (imported from GitLab project)
Created by: sashkab
They can start from whatever they want, but I don't want to have mess in my commits/comments, etc.
mysql> describe issues; +--------------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------------+--------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | title | varchar(255) | YES | MUL | NULL | | | assignee_id | int(11) | YES | MUL | NULL | | | author_id | int(11) | YES | MUL | NULL | | | project_id | int(11) | YES | MUL | NULL | | | created_at | datetime | NO | MUL | NULL | | | updated_at | datetime | NO | | NULL | | | position | int(11) | YES | | 0 | | | branch_name | varchar(255) | YES | | NULL | | | description | text | YES | | NULL | | | milestone_id | int(11) | YES | MUL | NULL | | | state | varchar(255) | YES | | NULL | | | iid | int(11) | YES | | NULL | | +--------------+--------------+------+-----+---------+----------------+ 13 rows in set (0.00 sec)So, iid is not auto_increment, not primary key. In notes, they use id field for references, not iid. Same thing for merge_requests table:
mysql> describe merge_requests; +-------------------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------------+--------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | target_branch | varchar(255) | NO | MUL | NULL | | | source_branch | varchar(255) | NO | MUL | NULL | | | source_project_id | int(11) | NO | MUL | NULL | | | author_id | int(11) | YES | MUL | NULL | | | assignee_id | int(11) | YES | MUL | NULL | | | title | varchar(255) | YES | MUL | NULL | | | created_at | datetime | NO | MUL | NULL | | | updated_at | datetime | NO | | NULL | | | st_commits | longtext | YES | | NULL | | | st_diffs | longtext | YES | | NULL | | | milestone_id | int(11) | YES | MUL | NULL | | | state | varchar(255) | YES | | NULL | | | merge_status | varchar(255) | YES | | NULL | | | target_project_id | int(11) | NO | | NULL | | | iid | int(11) | YES | | NULL | | | description | text | YES | | NULL | | +-------------------+--------------+------+-----+---------+----------------+So I don't see what making iid=id can brake, but for me fixes issue numbers mess. I never will have issue #1 (closed) in the project, but I don't care.
By Administrator on 2013-09-25T15:02:58 (imported from GitLab project)
