On Wed, Jul 24, 2013 at 3:28 PM, Chris Ryan <chris.ryan.12...@gmail.com>wrote:
> Thank you so much for the reply and help. I am not stuck with this
> database format and can change it as necessary. I will modify it as you
> suggested (let Django create the primary key, remove the ID suffix from the
> column names, etc.). I will then look for the managers as you suggested.
>
> I did find a solution to what I was trying doing. I was reading through
> the Python documentation and then through the Django documentation (for the
> up-teenth time) and discovered that I can "move backward" through the
> relationship chain easily (I'm still not sure what the proper phrase is for
> what I'm trying to do). For example, I can display the Family.Name by
> simply doing something like this:
>
> {{ object.TeacherID.ID.FamilyID }}
>
> So, now I can do something like this:
>
> {% if user.FamilyID = object.TeacherID.ID.FamilyID %}
>
>
> Or, after making the changes that you suggested I can do this (and use the
> actual ID numbers for comparison)
>
> {% if user.Family.ID = object.Teacher.ID.Family.ID %}
>
Yes, just so. By the way, going from a CourseCatelog instance to a Teacher
instance with object.Teacher is what most of us consider the forward
direction. It is relatively cheap in most databases, since it represents a
lookup on the primary key, and they tend to be "indexed" lookups. Going
the other direction, say from a Teacher instance to the set of
CourseCatalog instances that refer to that teacher is typically considered
the reverse direction, and is relatively expensive, since the database must
look in each row of the CourseCatalog table to see if it refers to the
given teacher.
Also, since it is the common convention, if you will make your field names
begin with a lower case character, others will have an easier time
following your code, and the habit will make you better able to follow
sample code, such as from docs.djangoproject.com. (Nominally, (variables
intended to represent) constants are all upper case, class names have each
word of the name begin with a capitol (as you have), attributes, such as
fields are all lower case with multiple words separated by the underscore
character (though you do see camel case). The "official" style guide is
PEP-8, http://www.python.org/dev/peps/pep-0008/ .
>
> Thank you again for the information that you provided. It will greatly
> help me move forward from here.
>
> -Chris
>
> You're welcome.
Bill
>
>
> On Wednesday, July 24, 2013 2:51:43 PM UTC-4, ke1g wrote:
>
>> First, is this a pre-existing data base whose format you are stuck with?
>>
>> While your models probably can be made to work, it is more common to let
>> Django take care of creating a single primary key in a model (called "id"
>> (lower case) by default).
>>
>> Also, while ForeignKey fields are implemented by storing the primary key
>> value of the desired row in the other table, that, too, is intended to be
>> hidden, so when you make a reference through a ForeignKey field, the ORM
>> actually hands you an instance of the foreign Model, not the id. That is:
>>
>> instanceOfCourseCatalog.**TeacherID
>>
>> is an instance of Teacher, not the TeacherID of a teacher. To get the id
>> integer, for those very rare cases in which it is valuable, you woudl use:
>>
>> instanceOfCourseCatalog.**TeacherID.TeacherID
>>
>> If you go the normal way and let Django create the primary key fields by
>> the default name "id", and if, to better describe what is happening,
>> removed the "ID from the end of your ForeignKey field names and, also a
>> convention, made them lowercase, the lines above lines would become,
>> respectively:
>>
>> instanceOfCourseCatalog.**teacher
>>
>> and
>>
>>
>> instanceOfCourseCatalog.**teacher.id<http://instanceOfCourseCatalog.teacher.id>
>>
>> In this case Django would have added a "manager" to the Teacher model
>> called "coursecatalog_set" (or just possibly "course_catalog_set", not
>> certain and don't have time to search the documents now), but whose name
>> your can specify with the "related_name" argument to the ForeignKey field.
>> This manager has all the usual queryset methods, so you can append ".all()'
>> to get an array of all the CourseCatalog objects with that Teacher. See
>> https://docs.djangoproject.**com/en/1.5/topics/db/queries/#**
>> backwards-related-objects<https://docs.djangoproject.com/en/1.5/topics/db/queries/#backwards-related-objects>
>>
>> Bill
>>
>>
>> On Wed, Jul 24, 2013 at 8:37 AM, Chris Ryan <chris.ry...@gmail.com>wrote:
>>
>>> I have spent hours trying to find the answer to this. What makes it even
>>> more frustrating is that I'm new to django development and not a real
>>> programmer by trade (I am a UNIX admin) so I am struggling to label what I
>>> am trying to do so that I can search for an answer.
>>>
>>>
>>> Here's what I have:
>>>
>>>
>>> In my models.py file I have the following class definitions:
>>>
>>>
>>> class Family(models.Model):
>>>
>>> ...
>>>
>>> FamilyID = models.AutoField(primary_key=**True)
>>>
>>> Name = models.CharField(verbose_name=**"Family Name")
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ------------------------------**------
>>>
>>>
>>> class FamilyMember(AbstractUser):
>>>
>>> ....
>>>
>>> ID = models.AutoField(primary_key=**True)
>>>
>>> FamilyID = models.ForeignKey(Family, blank=True, null=True)
>>>
>>> ...
>>>
>>> ------------------------------**------------------------------**
>>> ------------------------------**------
>>>
>>>
>>> class Teacher(models.Model):
>>>
>>> ...
>>>
>>> TeacherID = models.AutoField(primary_key=**True)
>>>
>>> ID = models.OneToOneField(**FamilyMember)
>>>
>>> ...
>>>
>>> ------------------------------**------------------------------**
>>> ------------------------------**------
>>>
>>>
>>>
>>> class CourseCatalog(models.Model):
>>>
>>> ...
>>>
>>> TeacherID = models.ForeignKey(Teacher, blank=True, null=True)
>>>
>>> ...
>>>
>>> ------------------------------**------------------------------**
>>> ------------------------------**------
>>>
>>>
>>>
>>>
>>> So, there is a table called Family that I belong to. It holds my family
>>> name and a couple of other fields.
>>>
>>> There is then a one-to-many relationship from that to the FamilyMember
>>> table. In this table I have a record for each member of my family.
>>>
>>> The FamilyMember table is also being used as the authentication table
>>> for my site. I have not replaced the default security model but only
>>> abstracted it and added additional fields.
>>>
>>> I am a teacher so there is also a record in the Teacher table. This
>>> table contains the FamilyMember.ID field.
>>>
>>> That's the setup for me. My main information is in the FamilyMember
>>> table and my FamilyMember.ID field is stored in the Family and the Teacher
>>> tables.
>>>
>>>
>>> On to the list of classes...
>>>
>>>
>>> There is a table called CourseCatalog that contains information about a
>>> class that I will teach. One of the columns is called TeacherID and this
>>> stores the TeacherID from the Teacher table. I set it up this way so that
>>> an admin can add a class and then assign it only to a teacher. The drop
>>> down list should not include FamilyMembers that are not teachers.
>>>
>>>
>>> Here are my questions and problems:
>>>
>>>
>>> - I want to log into the website as myself and modify only my classes.
>>> It would also be OK to modify the classes of everyone in my family. Either
>>> solution would be fine. However, I can't figure out how to do either of
>>> these things.
>>>
>>> - It seems to me that what I'm doing is trying to go backwards in the
>>> relationship chain. I have my CourseCatalog record that includes the
>>> TeacherID. I need to look that ID up in the Teacher table to get the
>>> FamilyMember.ID. I then need to use that to look up the record in the
>>> FamilyMember table. Once I have that, I can get the username and compare it
>>> to the username of the logged in user (me). Finally, I can filter on
>>> records where these two match.
>>>
>>> - I'm wondering if I have architected my database wrong. Is there an
>>> easier way to do this? Maybe I should get rid of the Teacher table and just
>>> use a boolean for teacher in the FamilyMember table. The concern that I
>>> have with this is when I start working on the Student table. I need to
>>> store more information about a student (allergy, emergency contacts, etc)
>>> and don't think it is appropriate to add those fields to the FamilyMember
>>> table because they are only used for students.
>>>
>>> - I'm asking for you experts to help guide me through this. Any advice
>>> is greatly appreciated.
>>>
>>> --
>>> 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...@**googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>>
>>> Visit this group at
>>> http://groups.google.com/**group/django-users<http://groups.google.com/group/django-users>
>>> .
>>> For more options, visit
>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>> .
>>>
>>>
>>>
>>
>> --
> 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 http://groups.google.com/group/django-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
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 http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.
