So serializers basically convert python native objects into json objects. 
Your viewset should be the one utilizing serializers. What you need to have 
is:

serializers.py:
class ProfileSerializer(serializer.ModelSerializer):
    class Meta:
        model = Profile
        fields = '__all__'

Basically, you don't need anything else in that serializer.

On Tuesday, June 25, 2019 at 7:46:42 PM UTC-4, Derek Dong wrote:
>
> I've been working more on this and have encountered the following issue 
> extending the User model into a Profile model:
>
> models.py:
>
> class Profile(models.Model):
>     user = models.OneToOneField(User, on_delete=models.CASCADE, 
> primary_key=True)
>     grade = models.PositiveSmallIntegerField()
>
>
> serializers.py:
>
> class UserSerializer(serializers.HyperlinkedModelSerializer):
>     class Meta:
>         model = User
>         fields = ('id', 'username')
>
>
>
> class ProfileSerializer(serializers.ModelSerializer):
>     user = UserSerializer()
>     scores = ContestScoresSerializer(many=True)
>     indices = ContestIndexSerializer(many=True)
>
>     class Meta:
>         model = Profile
>         fields = ('user', 'grade', 'scores', 'indices')
>
>
> views.py:
>
> class UserViewSet(viewsets.ModelViewSet):
>     queryset = User.objects.all()
>     serializer_class = UserSerializer
>
>
> class ProfileViewSet(viewsets.ModelViewSet):
>     """
>     API endpoint that allows users to be viewed or edited.
>     """
>     queryset = Profile.objects.all()
>     serializer_class = ProfileSerializer
>
>
> What am I doing wrong and how do I fix it? The problem is the Profile and 
> User models aren't linked; creating one doesn't create the other, nor does 
> updating or removing one affect the other.
>
> On Monday, June 24, 2019 at 10:00:21 PM UTC-4, Yoo wrote:
>>
>> Np!
>>
>> https://docs.djangoproject.com/en/2.2/ref/models/fields/#floatfield
>>
>> Just refer to the docs. There’s FloatField and DecimalField for models. 
>> When you show the numbers in views, just use python to round the numbers. 
>> There are plenty of tutorials and SO (stackoverflow) questions that’ll 
>> help. People on stack who like Django and want more rep points answer 
>> Django tagged questions, so questions are quickly answered. Like matter of 
>> minutes.
>>
>> Yea, I think all those details are confusing me, but veerrry logical in 
>> your mind since it’s your project. Here’re some things to keep in mind:
>>
>> Queries: Use them efficiently. Using that one table, ContestScores, we 
>> can find some scores for specific contests. We can write something like:
>>
>> from .models import ContestScores
>>
>> avar= ContestScores.objects.filter(contest=2)
>> thisvar = ContestScores.objects.filter(user=‘derek’)
>>
>> Using this, we have a queryset. Any records/rows with contest ID 2 in the 
>> ContestScores table will be in avar. In thisvar, any record that has a user 
>> named derek will be stored. 
>>
>> When making a queryset needs to be ordered by some system (I think it was 
>> descending scores), you can do this using the variables above: 
>> avar.order_by(‘-scores’) 
>>
>> Signals: something I avoided for awhile, but got the hang of pretty 
>> quickly. They have some cool little things like pre_save.
>>
>> from .signals import my_func
>> pre_save.connect(my_func, sender=ContestScores)
>>
>> #in signals.py in the apps directory
>>
>> def my_func(sender, instance, **kwargs):
>>     if instance.contest == 1:
>>         print(‘hello, you should probably do something with this 
>> function’)
>>     else:
>>          print(‘The contest for this record is Contest 1’)
>>     if sender == ContestID:
>>         print(‘the sender is a table, which in this case was ContestID’)
>>     else:
>>         print(‘hi’)
>>
>>
>> So, say someone created a new row in ContestScores. What’ll happen is, 
>> before the object is saved in the database, it’ll go through that function 
>> first. So if a user created a row setting the contest to be Contest 1, then 
>> you should see “Hello, you should...” and “hi”
>>
>> I imagine you could use signals for the Index(overall score. There’s 
>> something in databases called indexes). When showing the ranks of 
>> individuals, that’ll be done per request using the order_by method shown 
>> above.
>>
>> Regarding the semesters, I’d say just add another column to ContestScores 
>> called semesters, then use the filter(semesters=1, user=derek) or 
>> filter(semesters=1, contest=1). 
>>
>> The Django documentation is amazing, and can answer a lot of questions. I 
>> also said to use Django REST API. You don’t need to use it, but the reason 
>> I suggested it was because of its interface. Much smoother than the regular 
>> Django admin, but does require a little bit more work. Of course in 
>> production, you can disable it. I think of it as a neat debug toolbar.
>>
>> gl!
>>
>> On Mon, Jun 24, 2019 at 9:02 PM Derek Dong <philip6...@gmail.com> wrote:
>>
>>> I just wanted to add a question: I want to store the indices as floats 
>>> if possible, to at least 3 decimal places, and display them to the nearest 
>>> integer. Is this possible?
>>>
>>>
>>> On Monday, June 24, 2019 at 8:38:34 PM UTC-4, Derek Dong wrote:
>>>>
>>>> Thank you so much for the incredibly in-depth response, it's clarified 
>>>> quite a bit of how Django and databases work! I now realize how much I was 
>>>> overcomplicating things.
>>>>
>>>> s/a is a formula: the score of an individual divided by the top-15 
>>>> average.
>>>> The top-15 average is computed for each contest; as expected, it's the 
>>>> 15 highest scores, averaged.
>>>> Thus, it is very possible and, in fact, very common for multiple people 
>>>> to have the same index for a single contest.
>>>>
>>>> Think of the end goal as a cumulative grade for each person. 
>>>> So, say, for the first semester, Contests 1 and 2 could be extremely 
>>>> important and be weighted as 25% of the total grade each, with contests 
>>>> 3-7 
>>>> weighted 10% of the total grade each.
>>>> Then, in the second semester, Contests 1 and 2 contained material less 
>>>> relevant to what was studied in that time, and are weighted 5% each of the 
>>>> cumulative grade, with contests 3-7 still weighted 10% each and contests 8 
>>>> and 9 weighted 20% each.
>>>>
>>>> (Note: These aren't "grades," so don't worry about the ethics here. 
>>>> It's just I think this analogy works quite well to describe the system)
>>>>
>>>> I want to be able to query the rankings for the first semester and the 
>>>> second semester. For example, there could be a dropdown menu with the 
>>>> options "Semester 1" and "Semester 2" and if I select, say, the latter, a 
>>>> table will show the data for the second semester (Rank, Student, Grade, 
>>>> Overall Index, and indices for each contest contributing to that overall 
>>>> index). If you could point me in a direction for how to do this as well, I 
>>>> would appreciate it a lot!
>>>>
>>>> Thanks again for your care and thoroughness!
>>>>
>>>> On Monday, June 24, 2019 at 5:14:19 PM UTC-4, Yoo wrote:
>>>>>
>>>>> Gotcha. I’ll try my best to explain what you could try. And if this 
>>>>> looks sloppy, then I’ll make a public gist.
>>>>>
>>>>> So, firstly, let’s set some things straight. A database is a 
>>>>> collection of tables. Models in Django represent one table with multiple 
>>>>> columns. Tables do not need to have the same columns. What you’ve given 
>>>>> is 
>>>>> one table and appending lots of new attributes. That’s a non-relational 
>>>>> database that I advise you stay away from. 
>>>>>
>>>>> Here’s what I have in mind: there is a profile table. All users in 
>>>>> this table are in all contests.
>>>>>
>>>>> We’re gonna first ignore the Profile model from that link. That’ll be 
>>>>> the thing that houses student’s grade. Django has its OWN Users model 
>>>>> which 
>>>>> the Profile table extends from. Again, let’s ignore the Profile, for now. 
>>>>> First import the Django user model:
>>>>>
>>>>> from django.contrib.auth.models import Users
>>>>>
>>>>> Then,  based on what I’m imagining,  we’re going to make one table 
>>>>> called ContestID that can include Contest name(optional) and the main 
>>>>> behemoth, ContestScore:
>>>>>
>>>>> import uuid
>>>>>
>>>>> class ContestID(models.Model): 
>>>>>     id = models.AutoField(primary_key=True)
>>>>>     name = models.CharField(max_length=True)
>>>>>
>>>>> # You don’t have to have the id field since Django automatically 
>>>>> enables it if another attribute/column isn’t specified as primary key. I 
>>>>> just wanted to show everything
>>>>>
>>>>> class ContestScores(models.Model):
>>>>>     id = models.UUIDField(primary_key=True, default=uuid.uuid4, 
>>>>> editable=False)
>>>>>     contest = models.ForeignKey(ContestID, on_delete=models.CASCADE) 
>>>>>     user = models.ForeignKey(User, on_delete=models.SET_NULL)
>>>>>     score = models.PositiveIntegerField(default=0)
>>>>>     
>>>>> Alr, here’s what’s goin’ on. We have multiple contests listed in 
>>>>> ContestID. If they don’t have names, you can delete the names 
>>>>> column/line-of-code.
>>>>>
>>>>> Then in the table ContestScores, we have an id field called UUIDField. 
>>>>> In regular relational databases, row ids are unique. In your spreadsheet, 
>>>>> each record/row was unique by an incrementing row number. For us, this 
>>>>> might be several gazillionbillionakfhwjbxin rows, so we wanna be safe 
>>>>> with 
>>>>> this thing called Universally Unique Identifier.
>>>>>
>>>>> The contest column is a foreign key. This means the that this row 
>>>>> belongs to Contest 1 or Contest 2, etc.
>>>>>
>>>>> The score column is this user’s score based on a certain contest. The 
>>>>> user column specifies which user this record of scores belongs to.
>>>>>
>>>>> So in its entirety, the Contest table would “read” like this: in 
>>>>> Contest 1, the user Derek received a score of 94. We can find this record 
>>>>> at the id: ajbi02-kebo... (it’s 32 chars long).
>>>>>          
>>>>> Ok, it looks pretty useless right now. 
>>>>>
>>>>> Now, let’s implement that Profile table:
>>>>>
>>>>> class Profile(models.Model):
>>>>>     user = models.OneToOneField(User, on_delete=models.CASCADE, 
>>>>> primary_key=True) 
>>>>>     grade = models.PositiveSmallIntegerField()
>>>>>     index = models.PositiveIntegerField()
>>>>>
>>>>> Before I move on, I just need to clarify something: what is the index? 
>>>>> Is it s/a, and is the index unique for each student. Is “a” the average 
>>>>> of 
>>>>> all scores across all contests?
>>>>>
>>>>> The ranking system, if I’m not mistaken, is ranking the players the 
>>>>> ENTIRE TIME. So the number one person should have the highest index, s/a. 
>>>>>
>>>>> I’m clear on what the index is utilized for: ranking. I’m just not so 
>>>>> clear on how the index is calculated.
>>>>>
>>>>> If you decide you wanna learn this yourself, the best way is to learn 
>>>>> what a relational database is, like MySQL or PostgreSQL or SQLite. Just a 
>>>>> small visual explanation or just seeing a database like those will help 
>>>>> you 
>>>>> in the long run.
>>>>>
>>>>> But if you decide not to learn too much, because sometimes Django 
>>>>> becomes a lot too quickly, just clarify what the index is, and we’ll keep 
>>>>> going.
>>>>>
>>>>> On Mon, Jun 24, 2019 at 3:31 PM Derek Dong <philip6...@gmail.com> 
>>>>> wrote:
>>>>>
>>>>>> I'd like to specify my main problem a bit more.
>>>>>>
>>>>>> The biggest issue is how to implement the ranking system's 
>>>>>> calculations and input. The way it is currently done is manually on a 
>>>>>> Spreadsheet, which is functional but cumbersome in the event of a slight 
>>>>>> human error, as well as fact that the members change a bit. The way I 
>>>>>> implemented a Java app to deal with it is:
>>>>>>
>>>>>> The database is stored in a CSV file, in the form of a spreadsheet, 
>>>>>> with columns labeled: Rank, Name, Grade, Index (Overall score), Contest 
>>>>>> 1 
>>>>>> score, Contest 2 score, etc.
>>>>>>
>>>>>> To add a new contest's scores:
>>>>>> For every participating student:
>>>>>>     Enter the student's name
>>>>>>     Enter the student's grade
>>>>>>     Enter the student's score, s
>>>>>> End for
>>>>>> Find the top 15 scores' average, a
>>>>>> For every participating student:
>>>>>>     Compute s/a, find the student in the CSV, and append the result
>>>>>> For every student not added:
>>>>>>     If the student has a score for that contest already
>>>>>>         Leave it
>>>>>>     Else
>>>>>>         Append 0
>>>>>> If it's the student's first contest:
>>>>>>     Append a row with the student's name, grade, and 0's for all 
>>>>>> previous contests, completed with that student's index, s/a
>>>>>> For every student:
>>>>>>     Replace their Index with the average of all their contest scores
>>>>>> Sort the students by Index in decreasing order
>>>>>> Replace the CSV file with the new, completed data
>>>>>>
>>>>>> The problem with the Java program is it's cumbersome to store the 
>>>>>> numbers in a CSV and reread it each time, plus we already have a 
>>>>>> website, 
>>>>>> which combined with all the flexibility the ability to give each student 
>>>>>> a 
>>>>>> Profile makes the Django app so appealing.
>>>>>>
>>>>>> Does anyone have more specific ideas about how to implement this?
>>>>>>
>>>>>> As far the Django REST Framework goes, I'm not sure if making an API 
>>>>>> is really what I want to be doing here. As you can tell by how this app 
>>>>>> will be used, I'm a student who doesn't have much experience with 
>>>>>> "real-world" programming, especially those users can interact with 
>>>>>> easily. 
>>>>>> Sorry again if I'm not being clear, I'll try harder to specify what I 
>>>>>> mean 
>>>>>> if you need more.
>>>>>>
>>>>>>
>>>>>> On Sunday, June 16, 2019 at 9:49:07 PM UTC-4, Yoo wrote:
>>>>>>>
>>>>>>> Based off the context:
>>>>>>>
>>>>>>> https://simpleisbetterthancomplex.com/tutorial/2016/11/23/how-to-add-user-profile-to-django-admin.html
>>>>>>>
>>>>>>> I'm somewhat confused regarding where this is supposed to go, so 
>>>>>>> here're some random ideas which hopefully might help you start off with 
>>>>>>> some Google searches:
>>>>>>>
>>>>>>> The above link is implementing a Profile model, which kinda extends 
>>>>>>> the User model if that can help based off the context. Once you finish 
>>>>>>> the 
>>>>>>> tutorial above, runserver and access the admin at 
>>>>>>> 127.0.0.1:8000/admin and enter the user model to see all the fields 
>>>>>>> you added to the Profile model.
>>>>>>>
>>>>>>> When processing the numbers, you can define a function based on PUT 
>>>>>>> (update) requests. Or, whenever an object is created, a Django signal 
>>>>>>> can 
>>>>>>> be sent out to do some action like updating another table. 
>>>>>>> (Unfortunately, 
>>>>>>> I'm not too well-educated on signals...). 
>>>>>>>
>>>>>>> Indexes will have everything ordered based off your liking for 
>>>>>>> improved querying; otherwise, ordering will do the trick when using a 
>>>>>>> queryset (basically when you query for several tables, the server 
>>>>>>> returns 
>>>>>>> an ordering you specify e.g. ordered dates, numbers, letters, etc.). 
>>>>>>>
>>>>>>> Regarding authenticating users, you''ll have token authentication 
>>>>>>> and some Django decorators that'll allow you to specify when an 
>>>>>>> Authenticated User is allowed to do action X, Y, or Z. Unauthenticated 
>>>>>>> users would be blocked from certain pages by utilizing the 
>>>>>>> templates/html's 
>>>>>>> with tags {% if user.is_authenticated %} then your HTML then another 
>>>>>>> tag {% 
>>>>>>> else %} with other tags. There are plenty of other ways such as 
>>>>>>> redirecting 
>>>>>>> a user in the views.py and yada yada if the user is NOT authenticated.
>>>>>>>
>>>>>>> Something I think would help you is to utilize 
>>>>>>> Django-rest-framework. It's designed as an API, but I think you'll 
>>>>>>> understand Django much better through it. It's well-documented and 
>>>>>>> there 
>>>>>>> are plenty of tutorials (including those with Token authentication 
>>>>>>> which I 
>>>>>>> think you're seeking).
>>>>>>>
>>>>>>> On Sunday, June 16, 2019 at 8:13:05 PM UTC-4, Derek Dong wrote:
>>>>>>>>
>>>>>>>> How can I integrate OAuth with a ranking system in a Django 
>>>>>>>> application?
>>>>>>>> I'm not too familiar with Django design philosophy, which is why 
>>>>>>>> I'm asking these questions.
>>>>>>>> The way I understand it, OAuth doesn't let you manipulate 
>>>>>>>> information on the server authenticating a user, so I would still need 
>>>>>>>> a 
>>>>>>>> User model with information like "name." Is this right?
>>>>>>>> Some quick context:
>>>>>>>> Each user has float scores for each event (of which there are 
>>>>>>>> multiple); the average (or possibly total if that's easier) of these 
>>>>>>>> scores 
>>>>>>>> composes their overall score. Overall scores are used to rank all the 
>>>>>>>> users.
>>>>>>>> Should I have separate models for things like "score," "ranking," 
>>>>>>>> and/or "event?" 
>>>>>>>> Where should processing the numbers go? I assume I should make a 
>>>>>>>> form to input scores for each event, possibly with an overall "update" 
>>>>>>>> button on the admin page, but would that go in the model.py, admin.py, 
>>>>>>>> views.py, or something else?
>>>>>>>> Sorry for these questions possibly sounding strange, I'm used to 
>>>>>>>> object-oriented programming and have implemented a way to compute this 
>>>>>>>> in 
>>>>>>>> that way, but am confused by web applications' use of databases, 
>>>>>>>> views, and 
>>>>>>>> HTML for displays.
>>>>>>>>
>>>>>>> -- 
>>>>>> You received this message because you are subscribed to the Google 
>>>>>> Groups "Django users" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, 
>>>>>> send an email to django...@googlegroups.com.
>>>>>> To post to this group, send email to django...@googlegroups.com.
>>>>>> Visit this group at https://groups.google.com/group/django-users.
>>>>>> To view this discussion on the web visit 
>>>>>> https://groups.google.com/d/msgid/django-users/fca35f4a-7de9-4a41-88bb-e19e5edc9431%40googlegroups.com
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/django-users/fca35f4a-7de9-4a41-88bb-e19e5edc9431%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django...@googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-users.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-users/1fade4a7-1d26-418c-aded-a220fe562d5d%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-users/1fade4a7-1d26-418c-aded-a220fe562d5d%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8c8659e5-fdb8-4562-874d-a6617d491d48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to