#django

joshlegs: which is so counterintuitive because it’s literally running in production right now.

joshlegs: yea, well hopefully once i get comfortable with django my open source contribs won’t be too far away!

SteenJobs: you'll get it!! and that's why this channel exists -- helping people with the framework

joshlegs: amen. i mean the hardest part is to stop viewing everything through the lens of rails

yes i agree with you on that. it's a very very different framework

joshlegs: i figured running makemigrations would create a migration to fix the disparity between models.py and my db, but apparently not.

joshlegs: it’s healthy at first to conceptualize certain things as being analogous to rails, but in the end i have to totally detach.

^ agreed

SteenJobs: howd you get the database data anyway? only through fixtures or did you import a database?

joshlegs: like it saved me a ton of time to just realize virtualenv = RVM, compared to someone who’s never been introduced to the concept.

haha yep

joshlegs: merely cloned the repo, then ran migrate, then ran loaddata

but loaddata through an error because there were attributes listed in the fixtures which correspond to models.py but not to the current state of the db.

ahh. so fixtures is out of date.

i'd mention that to someone and ask if theres's a better way to get the db populated with data

joshlegs: heya!

joshlegs: you have really come a long way with python my friend!

emma: heya!! thanks i appreciate it!

emma: you learning django?

potentially. It's hard to say right now. I have to balance my learning curves with my needs

makes sense. i'd be more than happy to help if i can when you need it

(if you need it)

joshlegs: aright cool, i’ll look into other forms of seed data. in rails there’s a seed file that you use to literally seed your db.

SteenJobs: yeah, i think fixtures aims to scratch that itch, but it comes short a lot of times. i *think* the general recommendation is to use a datamigration

i've run into issues before where fixtures would be rerun each time you ran a migration if the data wasnt found -- and i needed some of that data gone. so, meh

Hi, I'm getting a very weird "Bad request (400)" error on my productions server (apache/modwsgi), with either DEBUG=True/False, but not during runserver and local dev. In order to attempt to debug I'm trying to set up logging to apache log

I have this config http://paste.ofcode.org/RJJJNQ3nkUtTYRvb4TPQyh for logging

If got an manually tamper wih the django source in say django.request and add a logger.error('something went wrong')

I do see it in the apache log

yet, nothing else is there upon making the request

I thought django would log at the 400 exception there?

fpghost84: SOmetimes BAd Requests in Production are the sign of a misconfiguration of ALLOWED_HOSTS. Did you try to set it to ('*',) ?

Yep, I've read that, and checked the ALLOWED_HOSTS, even trying ['*'] for test purposes

still get the 400

do foreign keys have a default related_name for when you want to use select_select related to do a reverse lookup? or do i need to explicitly set them

err that should say *select_related not 'select_select related'

I'm not very well versed in django logging, so I'm just trying to get a trace of the error in anyway possible

For example I'm not sure if what I wrote in my loggers key, namely '': {....} is the correct way

or if it should be 'django': {....} or even 'djang.request':{}

I just want to capture anything/everything

that is a possible error

fpghost84, You should read the logging docs https://docs.djangoproject.com/en/1.8/topics/lo..., but unfortunately it seems to be one of the more confusing part of django.

here is a sample logging configuration https://dpaste.de/nFWz

thanks

the logging, seems to be working, in the sense that I can logger.error('...) somewhere in the src and it shows in the apache logs

but I'm still no nearer to finding a trace on the 400 :(

and have no clear idea of how to even move fwd

joshlegs: would there be any rationale for django telling me there are no changes detected, yet models.py doesn’t match up with the columns in my db? is there a command for reconciling any differences?

Your apache may be misconfigured

SteenJobs: yeah i think so. this migration system is all new though and im not TERRIBLy familiar with it. trying to remember how its done now

#coderinsults

^heyts

joshlegs: well remember harder!!! jokes.

lol

to be honest, id start from scratch with the database and migrate it from scratch to see if that works

and then look at loading those fixtures and seing what happens then

joshlegs: already tried :D

:D

joshlegs: that’s my face i make when trying to maintain composure and not punching the dude next to me in the face. i’m not frustrated, it’s gonna be ok.

SteenJobs: other than that i realy dont know without looking at it myself. im not always the best at conceptualizing the problem described

and lol. i totally get that

iirc the new migration system dyamically determines what your database should look like based on the current migrations in your application, and then compares that against your database

so if you loaded data in from fixtures and it created tables that arent in the migrations, that could be a source, i'd think. but again, i'm really not sure

ok, /me needs to get back to his own programming dilemmas

nope. loading fixtures can’t create tables, would throw an error if the attributes are missing.

joshlegs---I finally switched over to mysql (random things took forever). It seems to work now!

django347: great!!

Thanks again for all the help

django347: i like mysql a lot. but im fairly sure that's just a bug with sqlite that hasnt been fixed yet

no problem!

Eh, well, somehow a field that I deleted lingered on in the new database, which gives me an error when I try to create the object that the [now deleted] field doesn't have a default/can't be null. I'm just going to drop my tables and delete all migration files to start fresh

joshlegs: im thinking of possibly making a django powered cms

joshlegs: have you done many things with django yet?

emma: yeah lots! a few silly game apps, and that's what i work in for my job. you ight look at django-cms -- i think it makes making cms'es a lot easier

joshlegs: oh cool thanks for the lead on that.

emma: yw! i think it's a pretty popular package/module

joshlegs: where im going to run into trouble is with the design/beauty aspect of it

django347: that sounds like a good idea

haha yeah i suck at design stuff too. :'(

joshlegs: is it tricky to theme a django site?

i'm like "just throw it in a box and that's good"

emma: like, what do you mean theme it? like find consistent styles etc?

Like make the whole site look unified and professional with some attractiveness.

so it doesn't look like something from 1996

ahh got ya

um, i generally suck at most things front end, but i think yeah it can be easy enough to theme the site.

bootstrap is really popular, and probably helps with that a lot

emma: There's nothing Django-specific about doing a theme, other than the template structure.

It's all still just HTML & CSS.

mattmcc: o/ good to see you round

which view gets called when viewing the admin change form for a given model in django?

mattmcc: thanks, I'm having a nightmare debugging a 400 in production (allowed hosts is set), so I think I need to trace through the admin code.