7

I was looking through my results from this cross-site query when I noticed that the results for the questions I asked on the Arqade meta pointed to http://meta.gaming.stackexchange.com/q/<####> instead of http://gaming.meta.stackexchange.com/q/<####> as expected.

I wouldn't have noticed this error, had it not been for the fact that the Arqade main site is blocked by a work filter, but ever since the change to site.meta... from meta.site..., I've been able to access the Arqade meta.

8
  • Arghhhhhhhhhhhhhh, yeah, I didn't even consider this. I think there's some logic in there somewhere that relies on the prior domain arrangement too |:
    – Tim Stone
    Jul 17, 2017 at 19:03
  • You should blame the creator of that query ... which happens to be me ... I'm looking into this and will answer.
    – rene
    Jul 17, 2017 at 19:40
  • @rene Not sure it's actually your fault...
    – MBraedley
    Jul 17, 2017 at 19:43
  • Or at least not entirely your fault.
    – MBraedley
    Jul 17, 2017 at 19:45
  • Well, we can blame Nick for the meta move ...
    – rene
    Jul 17, 2017 at 19:46
  • Looking a little closer at the query, if I'm understanding the #siteurl procedure correctly, it's reversing the order of the name column in the sys.databases table, using a dot as the delimiter. So the format for that column just needs to be changed to StackExchange.Meta.Site. No big deal, right?
    – MBraedley
    Jul 17, 2017 at 20:20
  • @MBraedley yeah, that is it. I'm working on a replacement of that procedure.
    – rene
    Jul 17, 2017 at 20:40
  • @rene: Here's something that seems to work, even if it's not as tidy as yours. That trick you're using with parsename() looks useful; I may want to try stealing it. (I kind of suck at T-SQL, in case you can't tell.) Unfortunately the lack of redirects for per-site metas of renamed sites makes having a bunch of special cases kind of inevitable (and I'm not even sure I've found all the sites that need them yet). Sep 6, 2017 at 22:03

1 Answer 1

6

I'm sorry that you have run into a bug on one of my queries and is caused by the recent switch of the meta domain names (from meta.[sitename] to [sitename].meta) to support https.

As multi-db query-ing is not formally supported in the public SEDE version the magic link generation for the urls will not work and therefor I relied on the databasename to generate the site url. It was a simple split by dot and reverse.

As that is no longer feasible I will update that query with a new version of the #siteurl procedure

-- create url based on dbname
create procedure #siteurl
   @dbname nvarchar(250),
   @res nvarchar(250) OUT
   as
   begin
      if @dbname = 'StackExchange.Meta' 
      begin
        set @res = 'Meta.StackExchange'
      end
      else
      begin
        declare @p1 nvarchar(250) = parsename(@dbname,1)
        declare @p2 nvarchar(250) = parsename(@dbname,2)
        declare @p3 nvarchar(250) = parsename(@dbname,3)

        set @res = 
          (case when @p1 = 'Meta' then @p2 else @p1 end) + 
          (case when @p2 is null then '' else '.' end) +
          (case when @p1 = 'Meta' then @p1 else isnull(@p2,'') end) +
          (case when @p3 is null then '' else '.' end) +
          isnull(@p3,'')     
      end;
   end;
go

This procedure will output the following for a given input (input > output)

StackExchange.Expressionengine.Meta > Expressionengine.Meta.StackExchange
StackExchange.Expressionengine > Expressionengine.StackExchange
Stackoverflow > Stackoverflow

which seems about right.

I have gone ahead and updated the query you used. It should render the correct urls for you.

Thanks for reporting.

You must log in to answer this question.

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