Skip to main content
Meta Stack Exchange

Return to Answer

awarded it is then
Source Link
rene Mod
rene Mod
  • 92.1k
  • 17
  • 245
  • 516

The list is sorted by the date when the bounty was "awarded". Technically we don't have that date but the PostNotice gets deleted at the same time, so

  • PostNotice.DeletionDate descending

should give you a close enough approximation of the order.

as proven by this SEDE query

select pn.postid [Post Link]
     , pn.creationdate
     , format(pn.deletiondate, 'yyyy-MM-dd HH:mm:ss:fffff') ["Awarded"]
from postnotices pn
where owneruserid = ##userid##
order by deletiondate  desc

Compare the oddness:

lines to indicate the match between UI order and query row order, highlight fields in records used in order by

For now this seems to be a stable order for your case. It might well be that the actual order by in the code turns out to be different and/or non-existing. The latter case is the prevalent implementation choice by SE developers. Not having an order by is more performant in which case the order of records is whatever SQL Server dreams up. 

Yes, this order might differ with each run of the query. Note that in case of a tie (see the bounties on 2022-11-13) it is left to SQL Server in what order to return rows. In fact, SQL Server can return a different order for that specific case with each execution of the query. In the end that is an internal implementation detail that might/will change with each version of SQL Server.

The list is sorted by the date when the bounty was "awarded". Technically we don't have that date but the PostNotice gets deleted at the same time, so

  • PostNotice.DeletionDate descending

should give you a close enough approximation of the order.

as proven by this SEDE query

select pn.postid [Post Link]
     , pn.creationdate
     , format(pn.deletiondate, 'yyyy-MM-dd HH:mm:ss:fffff') ["Awarded"]
from postnotices pn
where owneruserid = ##userid##
order by deletiondate  desc

Compare the oddness:

lines to indicate the match between UI order and query row order, highlight fields in records used in order by

For now this seems to be a stable order for your case. It might well be that the actual order by in the code turns out to be different and/or non-existing. The latter case is the prevalent implementation choice by SE developers. Not having an order by is more performant in which case the order of records is whatever SQL Server dreams up. Yes, this order might differ with each run of the query.

The list is sorted by the date when the bounty was "awarded". Technically we don't have that date but the PostNotice gets deleted at the same time, so

  • PostNotice.DeletionDate descending

should give you a close enough approximation of the order.

as proven by this SEDE query

select pn.postid [Post Link]
     , pn.creationdate
     , format(pn.deletiondate, 'yyyy-MM-dd HH:mm:ss:fffff') ["Awarded"]
from postnotices pn
where owneruserid = ##userid##
order by deletiondate  desc

Compare the oddness:

lines to indicate the match between UI order and query row order, highlight fields in records used in order by

For now this seems to be a stable order for your case. It might well be that the actual order by in the code turns out to be different and/or non-existing. The latter case is the prevalent implementation choice by SE developers. Not having an order by is more performant in which case the order of records is whatever SQL Server dreams up. 

Yes, this order might differ with each run of the query. Note that in case of a tie (see the bounties on 2022-11-13) it is left to SQL Server in what order to return rows. In fact, SQL Server can return a different order for that specific case with each execution of the query. In the end that is an internal implementation detail that might/will change with each version of SQL Server.

Post Undeleted by reneMod
awarded it is then
Source Link
rene Mod
rene Mod
  • 92.1k
  • 17
  • 245
  • 516

The list is sorted by the date when the bounty was created and postid"awarded". Specifically ordered by:Technically we don't have that date but the PostNotice gets deleted at the same time, so

  • date only descending
  • postidPostNotice.DeletionDate descending

should give you a close enough approximation of the order.

as proven by this SEDE query

select pn.postid [Post Link]
     , pn.creationdate
     , bodyformat(pn.deletiondate, 'yyyy-MM-dd HH:mm:ss:fffff') ["Awarded"]
from postnotices pn
where owneruserid = ##userid##
order by convert(date, creationdate) desc
       ,deletiondate postid desc

Compare the oddness:

lines to indicate the match between UI order and query row order, highlight fields in records used in order by

For now this seems to be a stable order for your case. It might well be that the actual order by in the code turns out to be different and/or non-existing. The latter case is the prevalent implementation choice by SE developers. Not having an order by is more performant in which case the order of records is whatever SQL Server dreams up. Yes, this order might differ with each run of the query.

The list is sorted by the date when the bounty was created and postid. Specifically ordered by:

  • date only descending
  • postid descending

as proven by this SEDE query

select postid [Post Link]
     , creationdate
     , body
from postnotices
where owneruserid = ##userid##
order by convert(date, creationdate) desc
       , postid desc

Compare the oddness:

lines to indicate the match between UI order and query row order, highlight fields in records used in order by

For now this seems to be a stable order for your case. It might well be that the actual order by in the code turns out to be different and/or non-existing. The latter case is the prevalent implementation choice by SE developers. Not having an order by is more performant in which case the order of records is whatever SQL Server dreams up. Yes, this order might differ with each run of the query.

The list is sorted by the date when the bounty was "awarded". Technically we don't have that date but the PostNotice gets deleted at the same time, so

  • PostNotice.DeletionDate descending

should give you a close enough approximation of the order.

as proven by this SEDE query

select pn.postid [Post Link]
     , pn.creationdate
     , format(pn.deletiondate, 'yyyy-MM-dd HH:mm:ss:fffff') ["Awarded"]
from postnotices pn
where owneruserid = ##userid##
order by deletiondate  desc

Compare the oddness:

lines to indicate the match between UI order and query row order, highlight fields in records used in order by

For now this seems to be a stable order for your case. It might well be that the actual order by in the code turns out to be different and/or non-existing. The latter case is the prevalent implementation choice by SE developers. Not having an order by is more performant in which case the order of records is whatever SQL Server dreams up. Yes, this order might differ with each run of the query.

Post Deleted by reneMod
Source Link
rene Mod
rene Mod
  • 92.1k
  • 17
  • 245
  • 516

The list is sorted by the date when the bounty was created and postid. Specifically ordered by:

  • date only descending
  • postid descending

as proven by this SEDE query

select postid [Post Link]
     , creationdate
     , body
from postnotices
where owneruserid = ##userid##
order by convert(date, creationdate) desc
       , postid desc

Compare the oddness:

lines to indicate the match between UI order and query row order, highlight fields in records used in order by

For now this seems to be a stable order for your case. It might well be that the actual order by in the code turns out to be different and/or non-existing. The latter case is the prevalent implementation choice by SE developers. Not having an order by is more performant in which case the order of records is whatever SQL Server dreams up. Yes, this order might differ with each run of the query.