#django

hard to figure out how exactly they interact

if a model has a foreignkey relationship to another model... for instance, I have a Match model that has exactly two Player models

Should i do Player1 = ForeignKey(Player) and player2 = ForeignKey(Player)? if so, how do i manage the related_name conflicts?

mekhami: you manage it by doing what the error says -- explicitly setting a related_name on the ForeignKey

if not, should I do a many2many relationship and somehow limit the number of acceptable related instances?

FunkyBob, in this case, what would I set related_name to? I've always just set it to what the related model calls this model, which in this case would be Match for both players

set it to whatever makes sense to you

but obviously you can't have the same related_name, or, if you can, it's still throwing me the same error

I'm not sure what does make sense to me

when you want to get to the matches where a player was Player1....

describe the relation, not the model

is there some implied difference between being player1 or 2 for a Match?

no

doesn't matter either way

does it, for instance, decide who serves first?

no

that gets decided randomly

and won't have any impact on this app

do most django devs use the admin panel with their apps or do they not

nacsurte: I use it to get started... and inspect what's going one

on, not one

nacsurte: yes, it's a very useful way to get started with your app

FunkyBob, were you heading somewhere with that last question? Cause I'm still a bit foggy

mekhami: I'd go with two fkeys... and just pick names like "player1_matches" and "player2_matches"

will this be difficult to work with later when i want to get all matches a player was in?

having to query both player2_matches and player1_matches to get total matches etc

not greatly, no

the real trick is forcing the two keys to never hold the same value

mekhami: When I've had a case like that, I've often found that in actuality there was some difference in the roles of the two players, and I could use more meaningful names for the two FKs

e.g. I have a system I'm working on that manages appointments between two participants, and rather than "participant1" and "participant2" I have "requestor" and "recipient", because one of the two parties requested the appointment.

(maybe in your case there is no such distinction at all, but something to consider)

yeah there really is no distinction, so i'm wondering if i even need two foreignkeys.

well, if there are always exactly two players, I still think two FKs is the best option.

+1

gratimax, FunkyBob: what about for production level apps

nacsurte: Sure, I've often used the admin. Not always. Depends if it meets a need in the project.

you can still use the admin, but be sure to secure it

It's been a long time since I've had a project where the admin really saw heavy use as the primary admin UI; usually it's not quite flexible enough for that. But even on those projects I often keep it around as a handy way for non-technical staff to peek "directly" into the db when necessary.

when i run tests using django.TestCase, it's not affecting my main database, right?

right

so why did i get the 'not null, no default, needs to populate existing rows' message from makemigrations when i haven't actually put anything in the main database?

mekhami: because it doesn't matter what's in it

it matters what _could_ be in it

ah

i always feel guilty setting null=True

what sort of field is it?

ForeignKey

it won't have a default, nor will it ever be null..

yeah... to add them you're usually best (1) add it nullable, (2) set values, (3) remove nullable

Hey, all, looks like the folks at #chicagodjango started a pretty great tutorial but never finished it! Anyone able to help me figure out a roadmap from here ? I am trying to create a dev environment in a Vagrant VM and write an Ansible playbook for a Python 2.7, Django 1.7, GeoDjango project. https://www.chicagodjango.com/blog/new-django-s...

"TypeError: create_user() takes at least 5 arguments (5 given)"

sounds a bit silly no?

heh

it's a Python thing