12

User with sufficient rep can see all recent reviews in some review queue: https://meta.stackexchange.com/review/close/history

User with lower reputation can still see a specific review if they have a link, for example https://meta.stackexchange.com/review/close/49400. (A link to a review can be obtained from various places, for example, timeline of a post, recent activity for a user who reviewed a post. Or simply by trying to enter link in the above format.

I want to ask whether the numbers of reviews grow consecutively. (For example, I linked above to a review numbered 49400. Does it mean that in some of the review queues, there will be review with number 49399?)

I did at least a bit of testing myself, and I was able to find reviews numbered 49400 and higher: 49400, 49401, 49402, 49403, 49404, 49405, 49406, 49407, 49408, 49409, 49410, 49411, 49412, 49413, 49414, 49415, 49416, 49417, 49418, 49419.

So the answer seems to be very likely yes, but it would be nice to have some official confirmation.

Improve this question
  • 1
    I think you can assume the next number will always be higher but most likely Sql Server autoincrement for the primary key is used and that implementation doesn't guarantee consecutive numbers, on restarts it might jump ahead a couple of 1000 numbers – rene Mar 4 '17 at 7:33
7

No, those ID's are not consecutive (at least for us mortals) as can be seen in this query:

-- https://stackoverflow.com/a/1312137/578411
SELECT  -- TOP 1
        -- Uncomment above for SQL Server 2012+
        previd
      , [Review Link]
FROM    (
        SELECT r.id
             , LAG(r.id) OVER (ORDER BY r.id) previd
             , 'site://review/' 
                + case 
                  when reviewtasktypeid=1 then 'suggested-edits'
                  when reviewtasktypeid=2 then 'close'
                  when reviewtasktypeid=3 then 'low-quality-posts'
                  when reviewtasktypeid=4 then 'first-posts'
                  when reviewtasktypeid=5 then 'late-answers'
                  when reviewtasktypeid=6 then 'reopen'
                  when reviewtasktypeid=10 then 'triage'
                  when reviewtasktypeid=11 then 'helper'
                  end
                + '/'
                + cast(r.id as nvarchar) 
                + '|'
                + rt.name as [Review Link]  
        FROM    reviewtasks r
        inner join reviewtasktypes rt on rt.id = r.reviewtasktypeid
        ) q
WHERE   (id - previd) > 100
ORDER BY
        id

As we don't see deleted posts in the reviewtasks table I decided to look for larger gaps, as small gaps (just one or two id's missing) is caused by those pesky deleted posts.

As for an possible explanation of the gaps in the identity column I refer to Why are there gaps in my IDENTITY column values?

big gaps

Improve this answer
  • Thanks! It seems very unlikely that there is some reasonable explanation for such large gaps. (In the case of the previous query we found out that some gaps were caused by deleted posts.) I will wait a bit before accepting an answer - just to see whether somebody has something reasonable to add to this topic. But I have to say - hat off to your SQL/SEDE skills. – Martin Mar 4 '17 at 9:34
  • @Martin I've added a link to a post on SO that explains why gaps appear in identity columns. Given the let's not reinvent the wheel approach of the SE Dev team I assume the default behavior of the identity column is causing what we see. – rene Mar 4 '17 at 9:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .