#django

wyoung: Oh, how did you get on with your stuff?

schinckel: I would still like your assistance if you are available :)

you guys ready for my question of the night? :P

just the guys, mind...

Valduare: s/guys/djangonites/

wyoung: I might be lightly available now: writing and running tests, so...

:D

schinckel: did you see the SQL query I was trying to create into an ORM expression? or should I send you the dpaste link again?

That was the UNNEST() stuff?

I have a model with a manytomany field, in my views I have the queryset and its returning the id’s of the manytomany field items.

yeah, UNNEST in FROM

how can I get the names instead of ids

schinckel: when used with group and aggregate it works quite sanely

Valduare: dpaste your models and your query code

group = group by

Maybe you'd better dpaste the query again.

objs = Message.objects.all().order_by('?')[0] im pulling a random record.

Valduare: and how are you getting the ids?

also, don't forget the handy first() method on queryset

obj.m2mfield.values_list('name', flat=True) <-- gets just a list of values from the name field

there’s so many options in django :) ty reading up on m2mfield and .values_list now

m2mfield was my guess are your many-to-many field name

because you refused to dpaste your models

oh i thought that was a special class heh

ok that works, ty values_list is what I was looking for

schinckel: will do!

schinckel: http://dpaste.com/22H6P1D

wyoung: Can you try using .extra(tables=['UNNEST(periods, days, weeks, months, years) AS u'])?

But that probably won't help with the column definitions anyway.

I think you probably won't be able to write that using the ORM.

:(

But, you could write a PG view that has that, and then put a model in front of that.

schinckel: isn't that hacky?

not really

unmanaged model

Then you'll just be able to treat it as a model class.

It's actually really neat.

add a migation to create the view.... sorted.

yeah, it seems nice in theory, I will need to do some experimenting

I use that pattern a lot.

in practice, it's been working for schinckel for years :)

Also, I use a nice system for versioning the SQL views too.

It is just shifting where you use raw sql though.

it lets the ORM treat the view like a table

schinckel: how do you go with versioning models? :)

<appname>/sql/<viewname>.view.000x.sql

Oh, that's versioning the VIEW, rather than the model.

right, is there a point versioning the sql when you don't version the model? they can be out of sync, especially if you have another migration that is doing something on a model when it is expected it to be a certain way,

You write the VIEW so that it doesn't require any parameters, and let PG push the query parameters to your queryset, so there's no injection worries.

Yeah, Django will create migrations even for unmanaged models (they just don't do anything in the db)

yeah I can express my UNNEST madness without requiring parameters. I just need to group on activity_id and period_unit

any way, bbl

Then, you update the VIEW as necessary (and have the correct version loaded into the db within the same migration as the Model update operation is).

I have a custom migration operation that loads the correct version of the VIEW (based on the version number), so reverse migrations work too.

app time, schinckel !

The only place it breaks is if you try to re-order view columns, or change their type.

Yeah. One day.

Maybe I'm saving that one for a presentation... ;)

I have a kind of conceptual database design question. I'm making a geospatial data visualization app. I have models representing various geographic subdivisions (zip codes, census tracts, etc.) Over time, I want to bring in lots of data sources that are reported on a per-region basis (e.g., income per capita). Should I just keep adding fields to the ZipCode model, or put each new data series on a separate table with a relation some

I'm kind of tempted to just put a JSONField called "data", and add keys over time. It's certainly easy. But it feels like it might be wrong. Any strong arguments against it?

hmm

hmm can I put variables in settings.py and call them in admin.py

Valduare: Yes, but what are you actually trying to do?

figured it be better to save an api key in settings.py

ah from django.conf import settings

this is what i was looking for