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-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/1fade4a7-1d26-418c-aded-a220fe562d5d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
