Django Web Framework: The 'D' is silent dumbass

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Django Web Framework: The 'D' is silent dumbass

«‹›122 »

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I kinda-sorta got it working but I have some issues server-side that I think come down to my weak understanding of websockets and Django's channel model. I can put it on its rear end just F5'ing the page a few times. The impression I get is that a consumer in the channel architecture will spin up and run for each unique connection; I won't have one of them sharing state across multiple connections. So I'm treating it kind of like a non-blocking server spinning off threads with a socket for each unique connection. These eventually--quickly, as it turns out--fill up and won't accept any more connections.

The tutorials and documentation were poopoo'ing closing the channels. I thought that was peculiar since I can't really see how it wouldn't know the free up resources from one of these connections. If I understand the model, then I have run exactly into this problem. I had even set up mechanisms to close the channel that currently no-op. I couldn't find a close() method to call. Do I have the right idea about this architecture? If so, how can I close these things?

If you want more specifics, then I have written a consumer to dispense a log file. It will do this until no new messages arrive after a certain time or I receive a special terminator in these log files. The client will connect and send me the name of the log it cares about. After that point, I just vomit out the lines as I get them using a variant on that FollowTail I previously mentioned.

I am finding that hammering on a client-side button that would bring in multiple requests as well as F5'ing a few times--with each refresh wanting to establish a new connection--overwhelms it. So I need a way to throttle those server-side. I also need a way to cancel ongoing connections when I refresh. This doesn't appear to happen.

So generally, how do I improve my robustness?

# ? Mar 6, 2017 06:28

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 22:31

NtotheTC: Dec 31, 2007

Do people still use django-angular (~~djangular? it seems to have different names...~~ nevermind they're different projects with the same name. yeesh.) at all? I've started work on a project where the previous developers used it and it just seems... awful. I get that "automatic" client side validation from django models is nice-to-have but whenever you need to create even a slightly custom widget you end up with a tangled mess where you're doing half the work in the django forms/widget code and half in js.

NtotheTC fucked around with this message at 17:36 on Mar 10, 2017

# ? Mar 10, 2017 17:25

Data Graham: Dec 28, 2009; 📈📊🍪😋

Sounds to me like an excellent way to trick yourself into thinking client-side validation is all you need.

# ? Mar 10, 2017 19:21

The Fool: Oct 16, 2003

Can anyone help me with the best way to turn this crap:

code:

var displaySearchResults = function(searchResults) {
    var output = '<div class="ui celled relaxed selection list">';
    searchResults.food.forEach(function(item) {
        output += '<div class="item">';
        output += '<div class="header">';
        output += item.name;
        output += '</div>';
        output += '<div class="ui horizontal list">';
        output += '<div class="item">';
        output += '<div>';
        output += "Calories: ";
        output += item.calories;
        output += '</div>';
        output += '</div>';
        output += '<div class="item">';
        output += '<div>';
        output += "Protien: ";
        output += item.protien;
        output += '</div>';
        output += '</div>';
        output += '<div class="item">';
        output += '<div>';
        output += "Fat: ";
        output += item.fat;
        output += '</div>';
        output += '</div>';
        output += '<div class="item">';
        output += '<div>';
        output += "Carbs: ";
        output += item.carbs;
        output += '</div>';
        output += '</div>';
        output += '</div>';
        output += '</div>';
    });
    $("#searchResults").html(output);
}

Into a sane django template?

# ? Mar 20, 2017 05:36

Data Graham: Dec 28, 2009; 📈📊🍪😋

code:

<div class="ui celled relaxed selection list">
{% for item in food %}
    <div class="item">
        <div class="header">{{ item.name }}</div>
        <div class="ui horizontal list">
            <div class="item">
                <div>Calories: {{ item.calories }}</div>
            </div>
            <div class="item">
                <div>Protien: {{ item.protien }}</div>
            </div>
            <div class="item">
                <div>Fat: {{ item.fat }}</div>
            </div>
            <div class="item">
                <div>Carbs: {{ item.carbs }}</div>
            </div>
        </div>
    </div>
{% endfor %}
</div>

# ? Mar 20, 2017 11:52

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

I released a new Django package this morning called django-cra-helper :woop:

A short summary of the project is that it simplifies using React components in Django templates. The slightly longer summary is that this ties together Django and create-react-app so that you can develop React as usual within the create-react-app dev environment, and then use the same components within a typical Django view template, all without changing any of the typical workflows associated with either project.

I tried to develop everything to be as turnkey as possible, and beyond adding a couple entries into settings.py it's pretty much set-it-and-forget-it. If you give it a try, I'm definitely interested in hearing your thoughts on it!

# ? Apr 3, 2017 17:26

MonkeyMaker: May 22, 2006; What's your poison, sir?

That looks awesome. I've been doing a livestream series building a Django and React app and it's been less than fun in several places. Wish you had released this two months ago

# ? Apr 3, 2017 20:05

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

IAmKale posted:

I released a new Django package this morning called django-cra-helper

A short summary of the project is that it simplifies using React components in Django templates. The slightly longer summary is that this ties together Django and create-react-app so that you can develop React as usual within the create-react-app dev environment, and then use the same components within a typical Django view template, all without changing any of the typical workflows associated with either project.

I tried to develop everything to be as turnkey as possible, and beyond adding a couple entries into settings.py it's pretty much set-it-and-forget-it. If you give it a try, I'm definitely interested in hearing your thoughts on it!

You are the best person.

# ? Apr 3, 2017 20:22

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

This should be pretty nice for a project I have coming up that is mostly template-based Django with a few parts of a few pages controlled by React.

Up to this point I've been doing React SPA's with DRF so haven't had a need to integrate with Django's templates at all.

# ? Apr 3, 2017 20:48

Count Thrashula: Jun 1, 2003; Death is nothing compared to vindication.; Buglord

MonkeyMaker posted:

That looks awesome. I've been doing a livestream series building a Django and React app and it's been less than fun in several places. Wish you had released this two months ago

Where is this series?? I'd love to watch it.

# ? Apr 4, 2017 13:04

MonkeyMaker: May 22, 2006; What's your poison, sir?

COOL CORN posted:

Where is this series?? I'd love to watch it.

YouTube. Start on episode 12.

# ? Apr 4, 2017 16:05

Count Thrashula: Jun 1, 2003; Death is nothing compared to vindication.; Buglord

MonkeyMaker posted:

YouTube. Start on episode 12.

Sweet, thank you

# ? Apr 4, 2017 16:19

epswing: Nov 4, 2003; Soiled Meat

If I want to update my Django app from 1.8 to 1.11, do I just start here https://docs.djangoproject.com/en/1.11/internals/deprecation/#deprecation-removed-in-1-9 and work my way up?

Or is there an "upgrade from 1.8 to 1.9" document that I should follow. Followed by "upgrade from 1.9 to 1.10" and "upgrade from 1.10 to 1.11"?

# ? Apr 4, 2017 20:05

a witch: Jan 12, 2017

run your tests with -Wall to get deprecation warnings. Upgrade and repeat as necessary.

https://docs.djangoproject.com/en/1.10/howto/upgrade-version/

a witch fucked around with this message at 20:14 on Apr 4, 2017

# ? Apr 4, 2017 20:10

epswing: Nov 4, 2003; Soiled Meat

a witch posted:

run your tests with -Wall to get deprecation warnings. Upgrade and repeat as necessary.

https://docs.djangoproject.com/en/1.10/howto/upgrade-version/

Any idea why 1.11 is not listed on this page?

https://docs.djangoproject.com/en/dev/internals/deprecation/

# ? Apr 4, 2017 20:19

porksmash: Sep 30, 2008

It seems like they have some work to do with docs still. I just swapped to 1.11 and I'm running into issues programatically rendering templates. The method described in the documentation now raises exceptions:

code:

TypeError: context must be a dict rather than Context.

Who'd have thunk that the context can't be a Context? Luckily the solution for me is easy - just stop wrapping my context dictionary with Context().

# ? Apr 5, 2017 20:36

hitze: Aug 28, 2007; Give me a dollar. No, the twenty. This is gonna blow your mind...

I've got two django sites, an internal one and an external one. I need to put data (not everything though) created on the internal one onto the external one. Is there a recommended way of doing this?

# ? Apr 6, 2017 01:54

porksmash: Sep 30, 2008

Attempting to upgrade to Django 1.11 is turning out to be a giant pain in the rear end. Things were kind-of starting to work after upgrading several packages, but now I'm dealing with segmentation faults with manage.py runserver which do not occur with 1.10. Has anyone run into this?

# ? Apr 12, 2017 20:07

epswing: Nov 4, 2003; Soiled Meat

I've got several sites running on Ubuntu 14.04, Python 2, Django 1.8. After finishing a couple projects, later this year I'm planning on upgrading them all to Ubuntu 16.04, Python 3, Django 1.11.

Not looking forward to it

# ? Apr 12, 2017 20:09

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

epalm posted:

I've got several sites running on Ubuntu 14.04, Python 2, Django 1.8. After finishing a couple projects, later this year I'm planning on upgrading them all to Ubuntu 16.04, Python 3, Django 1.11.

Not looking forward to it

Listed in order of likely difficulty/frustration from hardest to least hard.

# ? Apr 12, 2017 20:25

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Okay, I'm hoping that my typing out my question here I think of the answer like I do 99% of the time, but who knows!

I have a couple models:

Python code:

class Skill(models.Model):
  name = models.CharField(max_length=150)
  ... 

class Task(models.Model):
  name = models.CharField(max_length=150)
  ...

class TaskSkill(models.Model):
  task  = models.ForeignKey(Task, related_name='skill_scores')
  skill = models.ForeignKey(Skill)
  score =  models.IntegerField()

User can pick the three skills they think they are best at, and I need to do a bunch of stuff with that knowledge. I am having trouble figuring one of these stuffs out: Given three Skills, I want the Tasks that have scores for any of those Skills, and I want the Tasks to be annotated with the sum of the scores for those Skills, and ordered by said sum.

I'm having a couple problems, likely because I'm probably going about this entirely the wrong way since I rarely do Django these days. First, to get a list of things that have scores for any of those Skills, I am trying:

Python code:

Task.objects.filter(skill_scores__skill__id__in=(1,2,4))

I get a list, but the Tasks are repeated if it had several of the skills. So I "fix" that (I think?) with:

Python code:

Task.objects.filter(skill_scores__skill__id__in=(1,2,4)).distinct()

Seems okay to me! Now the hard part. In theory I should be able to annotate the result with the sum of the skill_scores__score right?

Python code:

Task.objects.filter(skill_scores__skill__id__in=(1,2,4)).distinct().annotate(summed_score=Sum(skill_scores__score))

But oh noes! NameError: name 'skill_scores__score' is not defined

This works:

Python code:

Task.objects.filter(skill_scores__score__gt=3).distinct()

So it can "see" the score, but somehow not when annotating? Any help with my approach, or suggesting a much better one, is appreciated!

# ? Apr 18, 2017 16:38

Pumpkin Pirate: Feb 2, 2005; ???????

Lumpy posted:

Python code:
Task.objects.filter(skill_scores__skill__id__in=(1,2,4)).distinct().annotate(summed_score=Sum(skill_scores__score))
But oh noes! NameError: name 'skill_scores__score' is not defined

This should be:

Python code:

Task.objects.filter(skill_scores__skill__id__in=(1,2,4)).distinct().annotate(summed_score=Sum('skill_scores__score'))

# ? Apr 18, 2017 17:57

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Pumpkin Pirate posted:

This should be:

Python code:

Task.objects.filter(skill_scores__skill__id__in=(1,2,4)).distinct().annotate(summed_score=Sum('skill_scores__score'))

Why yes, yes it should be. :smith:

Will this only sum the scores for the skills I filtered on, or all of them? If the latter, how do I constrain the annotation to the scores that match the three selected skills?

# ? Apr 18, 2017 18:09

Pumpkin Pirate: Feb 2, 2005; ???????

It should just use the filtered skills (see this section of the docs: https://docs.djangoproject.com/en/1.11/topics/db/aggregation/#order-of-annotate-and-filter-clauses ). You might need to get rid of the distinct() call, since the annotate makes a GROUP BY query, which will combine the duplicate rows.

# ? Apr 18, 2017 19:05

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Pumpkin Pirate posted:

It should just use the filtered skills (see this section of the docs: https://docs.djangoproject.com/en/1.11/topics/db/aggregation/#order-of-annotate-and-filter-clauses ). You might need to get rid of the distinct() call, since the annotate makes a GROUP BY query, which will combine the duplicate rows.

Thanks for your help! Everything is working and now I can go back to not using Django long enough to forget everything I just learned!

# ? Apr 18, 2017 21:24

epswing: Nov 4, 2003; Soiled Meat

I'm on Django 1.8, and I just hit the 30-char username limit. I'm using email addresses as usernames, and 30 is too short. There's been a whole discussion about this https://code.djangoproject.com/ticket/20846 and as of Django 1.10 the username max length is now 150. We are updating from 1.8 to 1.11 later this year, but I'm not sure what to do in the meantime.

I've looked at substituting a custom user model but that page is full of warnings about not doing that if you already have tables/data https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#substituting-a-custom-user-model

I just need to bump the limit up from 30, and whatever I end up doing, I plan on undoing before updating from 1.8 to 1.11, so I'm looking for a minimal, temporary solution, even if it's not pretty. I use my own views to handle user creation, so if Django's registration views don't work, that's fine.

# ? Apr 20, 2017 17:25

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

epalm posted:

I'm on Django 1.8, and I just hit the 30-char username limit. I'm using email addresses as usernames, and 30 is too short. There's been a whole discussion about this https://code.djangoproject.com/ticket/20846 and as of Django 1.10 the username max length is now 150. We are updating from 1.8 to 1.11 later this year, but I'm not sure what to do in the meantime.

I've looked at substituting a custom user model but that page is full of warnings about not doing that if you already have tables/data https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#substituting-a-custom-user-model

I just need to bump the limit up from 30, and whatever I end up doing, I plan on undoing before updating from 1.8 to 1.11, so I'm looking for a minimal, temporary solution, even if it's not pretty. I use my own views to handle user creation, so if Django's registration views don't work, that's fine.

If you're using your own views, you could just use your own model instead of django's User. In other words, use your own model and FK it to django's User.

# ? Apr 20, 2017 17:31

epswing: Nov 4, 2003; Soiled Meat

Thermopyle posted:

If you're using your own views, you could just use your own model instead of django's User. In other words, use your own model and FK it to django's User.

Maybe I spoke too soon about Django's views. I'm using Django's views for password changes, and password resets, but not user creation.

I'm looking for a low-impact temporary solution, so creating a whole new table, and keeping the two tables "in sync" doesn't sound like what I'm after.

Is a Proxy Model what I'm looking for? https://simpleisbetterthancomplex.com/tutorial/2016/07/22/how-to-extend-django-user-model.html#proxy

# ? Apr 20, 2017 18:05

porksmash: Sep 30, 2008

Updating from 1.8 to 1.10 was as easy for me as updating my template settings dictionary in settings.py and passing plain dicts instead of Context objects when programmatically rendering templates. That might be the lowest impact for you barring any third party package support issues.

# ? Apr 20, 2017 19:37

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

As an aside I had a workaround for a while that during registration took the email and then trimmed to 20 + added 10 random characters so I wouldn't have to worry about user character restrictions, and then changed the authentication method (which is pluggable in settings) to check email (which doesn't bear the character restrictions) instead of username.

It's completely unnecessary now that we're up to date on Django, but as a plus doesn't require any extra tables or anything so the changes are fairly low impact other than messing up your username data, but you can fix that up with a data migration once you're on later Django versions.

# ? Apr 20, 2017 23:01

NtotheTC: Dec 31, 2007

Not entirely Django specific but how do you guys handle versioning the virtualenv for any web apps you deploy? I feel like an md5 sum of the requirements file would work, but with nested requirements files (-r blah.txt etc) I'm not sure how best to follow the flow. I'm using fabric for my install script currently (I know docker would be better in the long run and I'll definitely be using it when I'm up to speed on it, but for now I'm just trying to get something functional in a hurry).

e: Do you even version virtualenvs? It seems useful to me because relying on pip install to correctly roll back to a previous state sounds shaky at best.

NtotheTC fucked around with this message at 18:07 on Apr 21, 2017

# ? Apr 21, 2017 18:03

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

NtotheTC posted:

Not entirely Django specific but how do you guys handle versioning the virtualenv for any web apps you deploy? I feel like an md5 sum of the requirements file would work, but with nested requirements files (-r blah.txt etc) I'm not sure how best to follow the flow.

I'm not sure what you're meaning here.

My requirements are versioned by default because my projects are stored in git. If I check out a tag or a branch, the correct requirements.txt is right there.

# ? Apr 21, 2017 18:06

NtotheTC: Dec 31, 2007

Thermopyle posted:

I'm not sure what you're meaning here.

My requirements are versioned by default because my projects are stored in git. If I check out a tag or a branch, the correct requirements.txt is right there.

Sorry I wasn't clear, I mean the actual virtualenv folder. So I deploy my project, create a virtualenv for it and pip install the requirements. Later I deploy a new version of the project and the requirements have changed, pip install updates the requirements but oh no I'm a retard and something's broken so I want to rollback, rolling back the code is fine but if I don't have a copy of the old virtualenv I then have to do pip install again and hope pip puts everything back the way it was and doesn't leave any random libs updated, or I have to delete the virtualenv and start over which would be quite slow in a crisis.

# ? Apr 21, 2017 18:10

a witch: Jan 12, 2017

I bundle the entire virtualenv into a pex file. Every deploy just wipes out the old pex so I always have the exact environment I want.

# ? Apr 21, 2017 18:19

Prancing Shoes: Jul 8, 2008

All of your requirements should be pinned. If you have a lot of requirements, you can use pip-compile from pip-tools to handle resolving the appropriate version for each requirements and pinning them. I use it to manage 200+ requirements and it's pretty easy.

https://github.com/jazzband/pip-tools

# ? Apr 21, 2017 18:22

NtotheTC: Dec 31, 2007

My requirements are pinned.. I guess I was thinking about tertiary requirements but pip tools could handle that. Maybe versioning the virtual environment isn't the way to go

# ? Apr 21, 2017 19:44

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

My virtualenv gets wiped on every deploy and my deploy pip installs the current requirement.txt.

At some point I switched over to hosting my own repository so my projects are less dependent upon PyPi.

Thermopyle fucked around with this message at 20:15 on Apr 21, 2017

# ? Apr 21, 2017 20:12

epswing: Nov 4, 2003; Soiled Meat

porksmash posted:

Updating from 1.8 to 1.10 was as easy for me as updating my template settings dictionary in settings.py and passing plain dicts instead of Context objects when programmatically rendering templates. That might be the lowest impact for you barring any third party package support issues.

Yeah we might just do this earlier than planned.

In trying to do so, I'm getting a bunch of RemovedInDjango20Warning warnings about on_delete becoming a required field (and to set it to models.CASCADE to maintain current behavior). That's all good, I've fixed my models in models.py.

However, python -Wall manage.py test is still complaining about all the ForeignKey statements in my migrations. Is this ok? Should I be modifying (*gasp*) my migrations?

Edit: The docs just say "The on_delete argument for ForeignKey and OneToOneField will be required." and don't mention anything about migrations.

But it's basically a no-op right? Just adding models.CASCADE is what those migrations were doing anyways by default?

Edit 2: After some struggling with getting psycopg updated, I've got things running on 1.11. Sweet.

epswing fucked around with this message at 21:36 on Apr 24, 2017

# ? Apr 23, 2017 17:19

epswing: Nov 4, 2003; Soiled Meat

In other news, I seem to be randomly getting this error:

quote:

ERROR (EXTERNAL IP): Invalid HTTP_HOST header: u'127.0.0.1:9000'. You may need to add u'127.0.0.1' to ALLOWED_HOSTS

Happens a few times a day, no discernible pattern
Doesn't seem to correlate to requests in nginx access_log or error_log
ALLOWED_HOSTS is set to ['.mydomain.com']
Ubuntu 14.04
Django 1.8 (and Django 1.11)
nginx 1.4.6
gunicorn 17.5

Can't find the source of these requests, not sure where to look at this point. Here's my SO post.

Any suggestions?

# ? Apr 24, 2017 21:36

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 22:31

Ahz: Jun 17, 2001; PUT MY CART BACK? I'M BETTER THAN THAT AND YOU! WHERE IS MY BUTLER?!

epalm posted:

In other news, I seem to be randomly getting this error:

Happens a few times a day, no discernible pattern

Doesn't seem to correlate to requests in nginx access_log or error_log

ALLOWED_HOSTS is set to ['.mydomain.com']

Ubuntu 14.04

Django 1.8 (and Django 1.11)

nginx 1.4.6

gunicorn 17.5

Can't find the source of these requests, not sure where to look at this point. Here's my SO post.

Any suggestions?

Nginx is likely forwarding requests as itself (127.x) so you can tell ngnix to maintain the original host header the request comes in as (domain.com).

# ? Apr 25, 2017 19:12

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Django Web Framework: The 'D' is silent dumbass

«‹›122 »