Conversation
This is a lot clearer since the tag table has a required community_id column. Tables / objects should be named by their ownership level, and these tags are created and maintained by communities. If in the future we want to add PersonTag, we can. - Fixes #6292
| @@ -1333,8 +1333,10 @@ diesel::allow_tables_to_appear_in_same_query!( | ||
| registration_application, | ||
| report_combined, | ||
| search_combined, | ||
| site, | ||
| site_language, | ||
| tag, | ||
| + person_actions, | ||
| + image_details, | ||
| ); | ||
| diesel::allow_tables_to_appear_in_same_query!(custom_emoji, custom_emoji_keyword,); |
There was a problem hiding this comment.
This is incredibly frustrating that just because tag is included in these lines, it breaks this entire section. I couldn't figure out how to fix this patch in this file.
There was a problem hiding this comment.
Editing the patch file manually doesnt work in my experience. You need to make a copy of the auto-generated schema file, then make the changes manually and generate a new patch file with diff.
There was a problem hiding this comment.
Thx, I think I got it.
|
This will likely produce a lot of conflicts with #6290, best to merge that one first. |
|
The reason we decided to name this table "tag" was that we agreed it can
later be expanded to support other tag types. Community Id used to be
optional but I decided there's no point in making it optional until it is
actually necessary. Migrating to it being optional is a very simple zero
cost (no locks) migration.
I don't think any of that has changed. Let me know if you want me to find
the previous discussion because this table has already been renamed twice -
it started out with a specific name which I then changed based on (I think)
@dessalines your comment.
El mar, 27 ene 2026, 18:27, Dessalines ***@***.***> escribió:
… @dessalines <https://github.com/dessalines> requested your review on:
LemmyNet/lemmy#6296 <#6296>
Renaming tag -> community_tag as a code owner.
—
Reply to this email directly, view it on GitHub
<#6296 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AARSOYKFBCIGE23P73GGJPL4I6NY3AVCNFSM6AAAAACSVZAKZOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMRSGMZDIMJXGY2DIMA>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
|
Without going over all that discussion again, I think going forward its easier to just have separate tag tables by ownership level. Then they won't have conflicting namespaces also. These tags are created by community owners and belong to communities, so its clearer to have them be I'm doing all the front end for this now and its much clearer. |
|
User tags would also be associated with a specific community (see #1456). There is also an issue for global user flairs but those would work in a completely different way. Other than those I cant think of any reasonable use for flairs which would be unrelated to a community. So this name change only makes it more explicit what the tags are used for. Edit: API tests need fixing. |
This is a lot clearer since the tag table has a required community_id column.
Tables / objects should be named by their ownership level, and these tags are created and maintained by communities.
If in the future we want to add PersonTag, we can.
TagtoCommunityTag#6292Unfortunately this PR breaks a diesel patch that adds
image_detailsandperson_actionsto the joinable entities, solely because this changes the name of the tag table which is on an affected patch line.I tried for like an hour to get this patch fixed, but I can't figure out how to do it properly.