Trying to implement user owned tags in django-taggit for specific objects
See original GitHub issueI am trying to implement a Video model in Django 1.11 which are tagged by both global tags (which are added by the admin when the video is first uploaded) which are able to be viewed by everyone accessing, and user specific tags (added by users per video) which are specific to the user logged in.
Currently, the model looks something like this:
class Video(models.Model):
video_name = models.CharField(max_length=50)
video_pub_date = models.DateTimeField('date published')
video_file = models.FileField()
video_thumbnail = models.ImageField(null=True, blank=True)
global_tags = TaggableManager()
video_views = models.IntegerField(default=0)
User model is just using from django.contrib.auth.models import User but not explicitly defined in my models.py
file
However, in addition to global_tags, I need a way to have private tags (user specific). This answer shows how to get tags for objects that are associated with a specific user, but this is not what I want since the object themselves (in my case Video), is not owned by anyone in particular, but the tags themselves are to be owned by specific user.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:5
- Comments:6 (1 by maintainers)
My solution was to adapt django taggit as a local app. then I modified the TagBase to remove the uniqueness for ‘name’ and ‘slug’ fields. I also added a user foreignkey.
This feels a bit backstabby to Django, but for the past 2 years, I’ve used idomatic Go to write my backends [for both work and personal projects] (rolling my own native SQL queries using the Go std lib without ORM’s etc.) and I’ve never looked back.
Basically in my experience, once you write your Django app, you still have to put in a significant effort in optimizing your backend to maximize cores by using a WSGI, managing dependency during production execution. However, with Go, the default
go build
command builds a production ready fully non-threaded backend executable that you can just start running, and reverse proxy requests to (which is far easier to manage during production execution).At the same time, because of the strong support for most backend related logic in the standard library, you can always r.y.o model classes no problem
I would encourage anyone having trouble Django or Rails to check out Go.