#django

temhaa: is this for a dev setup where django will be serving your static files or are you trying to have them served by a web server?

well, either way, https://docs.djangoproject.com/en/1.8/howto/sta... explains what to do

farn currently dev setup. but I will deploy to web server after after

farn: How setting I apply to my settings, what is your suggestion

hi, i'm trying to use the pip pckg django-db-mutex, and i'm getting the following error: 'relation "db_mutex_dbmutex" does not exist' whenever i try to initiate the mutex lock. upon inspection, it seems like the db-mutex package requires a 'DBMutex' model to be created in the database. what's the correct way to makemigrations that detects this requirement? i've tried copying/pasting the model into my models.py but that doesn't work.

temhaa: have you added the url patterns as described in https://docs.djangoproject.com/en/1.8/howto/sta...

farn: So Should I use when deploy to web server

temhaa: I don't understand that question

are you asking what you should use?

farn: If I use web server so how can I configure

looking into the package's code, i see a models.py there (/usr/local/lib/python2.7/dist-packages/db-mutex/models.py). how do i get migrations to pick up on it?

farn: not dev

temhaa: you set STATIC_ROOT to the path that your web server serves as /static/ and run `manage.py collectstatic`, as explain on https://docs.djangoproject.com/en/1.8/howto/sta...

anyone? :\

boxbeatsy: mkdir migrations

boxbeatsy: oh that won't work in your case

boxbeatsy: you can't force migrations on a third party app

boxbeatsy: if migrate doesn't work, I dunno. did you add it to INSTALLED_APPS?

Knyght: ooooo, doh. no, i didn't add it to INSTALLED_APPS.

boxbeatsy: well there's your problem :) if I read your question properly I might have even got it the first time instead of the fourth, but I'll blame the weekend

Knyght: :) thanks. i'm getting a subsequent warning now that's leading to the same error: "/usr/local/lib/python2.7/dist-packages/db_mutex/models.py:4: RemovedInDjango19Warning: Model class db_mutex.models.DBMutex doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9. class DBMutex(models.Model):

weird, because that's a new warning that i only get after i add db_mutex to installed_apps

boxbeatsy: sounds like it's a problem with the module. it doesn't affect you for now but maybe ad an issue to fix it on their github if there isn't already one

package, not module ;x

Knyght: gotcha. for some reason, even after i add it to installed_apps, it's not detecting the package's model definitions. error being: relation "db_mutex_dbmutex" does not exist

hmm

did you run migrate?

ya, and it didn't detect any changes. it did out put that warning though

"Model class db_mutex.models.DBMutex doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded"

yeah I don't think it should be a problem, not sure

hmm, ok

Knyght: nevermind, i was running makemigrations not migrate. all set. thanks!

\o/

is there something similar to InlineModelAdmin to use with class based views? where you can have your user model and a one-to-one profile model at the same time?

I wish there was.

the answer to your first question is inline formsets, but I don't think you can use those with one-to-one relations

beastDivision, look at django-extra-views

thanks!

When designing a ReSTful api for things like this: http://puu.sh/jT7Hx/4141e2884f.png when you have several instances of an object which is meant to display data of some linked model, like in this case, these are tasks that display the avatar and username of users, and aggregate information of time reports. Would you design the api to give you a list of task objects with the user profile and time information

nested?

Or would you use hyperlinking that would have to be resolved for every task?

depends

having to make many requests hurts so materializing might be better

What would be the drawbacks?

the materializing call is going to hit your db and cpu harder

Hm right

I think I'll go with what makes simplest code right now and then optimise later. Thanks

Another question: In templates when referring to things like static urls and such, you can use the {% static %} tag, or {{ STATIC_ROOT }} or such to find the files. But if you write a lot of the website in client side angular js code served by static files, how would you deal with supplying which URL things are at?

For example, in development, they reside under localhost, but I might want a real domain based URL in production

Is there nothing django can do about it since it is statically served files? Should I use angular JS settings somehow, or should I turn the .js files into proper django rendered templates?

Okay I am getting a QueryDict from ModelSerializer from DRF

How do I get it to json?

Do I just do a json.dumps() on that?

DarkSector, models to json is typically YourSerializerClass(instances, many=True).data

Yeah that was my mistake

.data

it's covered in http://www.django-rest-framework.org/tutorial/1...

dang`r`us content = JSONRenderer().render(serializer.data)

it has to be dumped

json.dumps needs to be done on .data()

*data

well, you get the idea

So I have this code, and I reckon it could be all done in one query, but I'm not sure how. Just in case anyone wants to take a crack at it: https://dpaste.de/U0ce (the select_related() is used later, and also need to keep the list around for something else after)