Flair_url is always NULL in SQL query?

Development

AI-generated summary

The flair_url column in the groups table is always NULL when queried through SQL, despite having an image uploaded. This is because the column is no longer used and is ignored in the Discourse code david.

Instead, the flair_upload_id column can be used to retrieve the upload URL by joining the groups table with the uploads table, as suggested by JammyDodger:

SELECT g.name,
        g.flair_upload_id, 
       u.url, 
       u.original_filename
FROM groups g
JOIN uploads u on g.flair_upload_id = u.id

This workaround has been confirmed to work by piffy. It’s recommended to drop the flair_url column in a post-deploy migration, as suggested by vinothkannans.

1

I’m working on a plugin that uses the Group flair image.

When I perform a SQL query to grab the flair_url from the groups table, it returns NULL for every group despite having an image uploaded. The Discourse data explorer plugin also confirms this (SELECT flair_url from groups)

image
image387×540 2.64 KB

However, the /g.json page does provide a valid flair_url:

image
image870×127 12.6 KB

What’s up with this? is there some quirk about fetching this url that makes it hard to get from a SQL query? I’m still pretty new to Ruby and Rails so I don’t know exactly where I would look in the Discourse source to figure this out. I did notice on line 9 on app/models/group.rb that the flair_url is added to “ignored_columns”, - I’m not sure what the implications of that are, if any.

Just wondering if this column appearing NULL is intentional and if so, I would appreciate any tips to get that data from the Ruby back-end of my plugin

2

I think the data from that column may have been moved at some point. flair_upload_id seems promising:

SELECT g.name,
       g.flair_upload_id, 
       u.url, 
       u.original_filename
FROM groups g
JOIN uploads u on g.flair_upload_id = u.id
3

Thanks! This seems like a bit circuitous but it worked! :grin:

4

Yeah, the flair_url column isn’t used any more - we tell Rails to ignore it in our ruby code:

Looks like that’s been the case for a while now. @vinothkannans any reason we shouldn’t go ahead and drop it in a post-deploy migration?

5

Yes, we should drop it now. We already passed that time long ago.