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 »

Fluue: Jan 2, 2008

Thermopyle posted:

The goal of DDD is largely about helping you understand your own codebase when the business logic gets too complicated. Sure, if I was designing from scratch, I'd probably do all api requests and caching from a services module, but if you're not having a hard time with the complexity I think I'd leave them where they are but use django's @cached_property decorator and not worry about caching the values on the object instance myself.

Good point. Didn't know about the @cached_property! Will convert my @property decorators over to that.

I think a lot of the complexity I'm facing comes down to a poorly designed data model from the business, so I'll need to go back and rethink some of this to see if I can paper over any of it.

# ? Apr 18, 2018 19:45

Adbot: ADBOT LOVES YOU

# ? May 31, 2024 23:20

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

Fluue posted:

Good point. Didn't know about the @cached_property! Will convert my @property decorators over to that.

I think a lot of the complexity I'm facing comes down to a poorly designed data model from the business, so I'll need to go back and rethink some of this to see if I can paper over any of it.

The way cached_property works is pretty neat.

On first access it retrieves or calculates the value you're looking for and then it replaces itself on the instance. One benefit to this is that it's faster to access then the typical practice of storing the calculated value in another instance attribute like self._im_the_real_value.

Either way you do it, you have to remember that its cached. Typically, a model instance is pretty short lived...you retrieve it and get an attribute or two off of it. However, if you do something like instance.refresh_from_db(), and your cached property uses values from the db in its calculation, your property is now wrong and out-of-date.

# ? Apr 19, 2018 20:53

F4rt5: May 20, 2006

Sorry to bother you with what is probably a simple problem but my search skills (or comprehension of the Django docs) have failed me.

I keep getting this error:

code:

NoReverseMatch at /dashboard/
Reverse for 'location-detail' with no arguments not found. 1 pattern(s) tried: ['dashboard\\/location\\/(?P<id>[0-9]+)\\/$']

It looks like I've done everything correctly, but I'm not sure.

Main urls.py:

code:

urlpatterns = [
    path('accounts/', include('django.contrib.auth.urls')),
    path('admin/', admin.site.urls),
    path('dashboard/', include('barstock.urls', namespace='dashboard')),
] + static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)

the barstock/urls.py:

code:

app_name = 'dashboard'

urlpatterns = [
    path('', views.index, name='dashboard'),
    path('location/<int:id>/', views.location_detail, name='location-detail'),
    path('storagearea/<int:id>/', views.storagearea_detail, name='storagearea-detail'),
]

the barstock/views.py:

code:

@login_required
def location_detail(request, id):
    location = get_object_or_404(Location, pk=id)
    context = {
        'location': location,
        'storageareas': StorageArea.objects.filter(location_id=location.id),
    }
    return render(request, 'barstock/location/detail.html', context)

and the template code that apparently triggers it:

code:

{% for location in locations %}
    <li><a href="{% url 'dashboard:location-detail' %}{{ location.id }}/">{{ location.name }}</a></li>
{% endfor %}

The error appears whether I namespace the urls with app_name= or not. Probably something simple, but what gives?
if I use hard-coded URLs in the template it works fine and will display that location and its storageareas:

code:

<a href="location/{{location.id}}">{{ location.name }}</a>

That works.

e: fixed url example above

e2: Jeez, I don't understand this at all. If I create a slightly different URL pattern, removing the namespacing and app_name like so:

code:

path('locations/', views.locations, name='location-index'),
    path('locations/<int:id>/', views.locations, name='location-detail')

and add a default for 'id' in the view and some other stuff to display either an index or a location detail:

code:

def locations(request, id=False):
    if id == False:
        locations = Location.objects.filter(owner_id=request.user.id).order_by('name')
        storageareas = False
        return render(request, 'barstock/location/index.html', {'locations': locations})
    else:
        location = get_object_or_404(Location, pk=id)
        storageareas = StorageArea.objects.filter(location_id=location.id)
    context = {
        'location': location,
        'storageareas': storageareas
    }
    return render(request, 'barstock/location/detail.html', context)

using {% url 'location-index' %} in the main menu goes to /locations and I can use {% url 'location-index' %}{{ location.id }} in the index view to get a specific location but {% url 'location-detail' %} throws the same NoReverseMatch error... I'm out of my league here.

F4rt5 fucked around with this message at 10:45 on Apr 28, 2018

# ? Apr 28, 2018 07:02

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

Dominoes posted:

Hey dudes. Looking for wisdom on what URL to query for Django Rest tied to a Create-React-App setup.

Setup: standard, unejected CRA folder inside Django folder. Django's static and temple settings point to frontend/build. Dummy package.json in main folder that tells Heroku which node version and packages to install, then points to the real one in frontend, which commands a build on install.

I'm assuming you are familiar with CRA's ability to proxy requests for you so you can just use "real" URLs in development? https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md#proxying-api-requests-in-development

# ? Apr 28, 2018 15:57

BaronVonVaderham: Jul 31, 2011; All hail the queen!

JazzmasterCurious posted:

URL pattern issues

It's because of how you defined your url pattern I think. The error is specific: "Reverse for 'location-detail' with no arguments not found."

Your url pattern:

code:

path('location/<int:id>/', views.location_detail, name='location-detail')

This takes a single argument "id", which needs to be included inside your {% url %} tag, not appended to the url manually. You want to do:

code:

{% url 'dashboard:location-detail' location.id %}

If you want to also include the name you'll need to add another argument to your URL string, but you don't appear to be using it anyway. But that's why if you manually constructed the href in your a-tag it worked fine, then the URL matched an expected pattern. When you use the django url tag (as you properly should be and are), you need to treat it more like a function call with your arguments.

Hope that helps!

# ? Apr 28, 2018 17:00

F4rt5: May 20, 2006

^^^ Thanks for the kind help; it worked perfectly. I didn't know about being able to send parameters in a {% %} tag, it makes much more sense now. Thanks again!

# ? Apr 30, 2018 06:13

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

So let us say I have an app and it's running in three environments (dev, staging, production). I on occasion need to add a model instance via the admin so a picker in the app has a new entry. Currently, I am doing this the stupid way by going to each environment and manually adding. How do smart people do this? All my :google:

is returning page after page of how to get different settings across environments because apparently I can't think of a way to phrase my search without that happening...

# ? May 4, 2018 14:44

Eleeleth: Jun 21, 2009; Damn, that is one suave eel.

Without knowing more about the context, I'd think about writing a data migration ( https://docs.djangoproject.com/en/2.0/topics/migrations/#data-migrations ) to add the necessary instances on deploy, since it sounds like the data is relatively static across all your environments.

# ? May 4, 2018 15:13

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

Eleeleth posted:

Without knowing more about the context, I'd think about writing a data migration ( https://docs.djangoproject.com/en/2.0/topics/migrations/#data-migrations ) to add the necessary instances on deploy, since it sounds like the data is relatively static across all your environments.

That looks pretty spot on. Thanks! And yeah, the cases where I'm doing this are for mostly-static things like options in a dropdown and so on that don't change between environments.

# ? May 4, 2018 15:38

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

Is it possible to package up an entire django project?

In the docs I saw this page about packaging an app: https://docs.djangoproject.com/en/2.0/intro/reusable-apps/#packaging-your-app

In that case it seems like it's just packaging up "polls" - I want to package up all of "mysite" though, settings, templates, etc

I was thinking this would simplify deployment a bit, turning it into just a "pip install my_site" followed by a collectstatic & migrate

# ? May 9, 2018 02:38

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

fletcher posted:

Is it possible to package up an entire django project?

In the docs I saw this page about packaging an app: https://docs.djangoproject.com/en/2.0/intro/reusable-apps/#packaging-your-app

In that case it seems like it's just packaging up "polls" - I want to package up all of "mysite" though, settings, templates, etc

I was thinking this would simplify deployment a bit, turning it into just a "pip install my_site" followed by a collectstatic & migrate

git?

# ? May 9, 2018 02:48

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

Lumpy posted:

git?

Yeah that's what I'm currently doing, would prefer to pull a build artifact from internal pypi server rather than source control though.

# ? May 9, 2018 08:08

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

fletcher posted:

Yeah that's what I'm currently doing, would prefer to pull a build artifact from internal pypi server rather than source control though.

ah, gotcha.

# ? May 9, 2018 15:10

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

I'm thinking that given how little information I am finding out there about how to do this, it may be a sign. I am surprised nobody else is doing this though...

# ? May 10, 2018 01:09

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

I'm just not sure what you're hoping to gain over other methods of getting your code on the server.

# ? May 10, 2018 01:16

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

Yeah, I mean:

code:

git clone
pip install -r reqs.txt
./manage.py migrate

Isn't exactly tedious.

# ? May 10, 2018 02:24

epswing: Nov 4, 2003; Soiled Meat

Python code:

class Parent(models.Model):
	pass

class Child(models.Model):
	parent = models.ForeignKey(Parent, on_delete=models.PROTECT, related_name='children')

	def save(self, *args, **kwargs):
		if self.parent is None: # error happens here
			self.parent = Parent.objects.create()
		super().save(*args, **kwargs)

c = Child()
c.save()
# django.db.models.fields.related_descriptors.RelatedObjectDoesNotExist: Child has no parent.

What I want is: if saving a Child without a Parent, create a new Parent. I get the above RelatedObjectDoesNotExist when executing if self.parent is None. I've tried if not self.parent as well, same error on the same line.

What am I doing wrong here? I don't really want to make the parent field nullable. It's like just the act of reading self.parent, even to check if it's None, is enough to trigger the error.

This is in Django 1.11, here's where the error is raised: https://github.com/django/django/blob/2b882a4bd954c8a6b1447f8fc0841a3352514c26/django/db/models/fields/related_descriptors.py#L193, so if I'm reading this right, just by reading self.parent, I'm ending up in that __get__. So how can I give it a value if it's None, if I can't check that it's None?

Edit: Oops... of course, I should be reading self.parent_id instead of self.parent. Duh.

epswing fucked around with this message at 13:40 on May 10, 2018

# ? May 10, 2018 05:11

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

Lumpy posted:

Yeah, I mean:
code:
git clone
pip install -r reqs.txt
./manage.py migrate
Isn't exactly tedious.

Yeah, agreed it's definitely not tedious the existing way I'm doing it.

I guess part of the problem is that deployments are usually done during off hours, and occasionally this means that our git server is also undergoing maintenance at the same time we want to do a deploy to production. It'd be nice to eliminate that dependency, with an s3 backed pypi repo I wouldn't have to worry about it. I can achieve the same goal just my creating an archive and uploading it somewhere, it just seemed like something that setup.py would have been able to handle for me.

fletcher fucked around with this message at 06:24 on May 10, 2018

# ? May 10, 2018 06:17

NtotheTC: Dec 31, 2007

There's things like fabric (but I don't know if that's python3 compatible yet?)

But the reality is when you want to start doing things "properly" you have to start looking at things like docker

# ? May 10, 2018 11:56

Ghost of Reagan Past: Oct 7, 2003; rock and roll fun

fletcher posted:

Yeah, agreed it's definitely not tedious the existing way I'm doing it.

I guess part of the problem is that deployments are usually done during off hours, and occasionally this means that our git server is also undergoing maintenance at the same time we want to do a deploy to production. It'd be nice to eliminate that dependency, with an s3 backed pypi repo I wouldn't have to worry about it. I can achieve the same goal just my creating an archive and uploading it somewhere, it just seemed like something that setup.py would have been able to handle for me.

If this occasional git server outage is annoying enough to eliminate as a dependency, you might be at the point where you want a dedicated build and deploy system. But one way to do that is not as a pip package, but as a deb or rpm, or just a tarball you untar on the destination server. If you go that route, you can install dependencies into a virtualenv and run collectstatic prior to the packaging so nothing happens on the actual servers.

I suggest this route because this way you don't have to gently caress with dependencies at deploy.

Or docker :shrug:

# ? May 10, 2018 12:57

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

WTF, why is your git server down for maintenance so much that you would even be looking into doing this.

# ? May 10, 2018 15:05

huhu: Feb 24, 2006

Is there a less ugly way to do this? Specifically the bit about correct_answer_id = -1.

code:

q = Question(text=question, correct_answer_id = -1)
q.save()

a = Answer(text=answer, question=q)
a.save()

q.correct_answer_id = a.id
q.save()

for d in detractors:
    a = Answer(text=d, question=q)
    a.save()

# ? May 23, 2018 18:54

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

huhu posted:

Is there a less ugly way to do this? Specifically the bit about correct_answer_id = -1.

code:

q = Question(text=question, correct_answer_id = -1)
q.save()

a = Answer(text=answer, question=q)
a.save()

q.correct_answer_id = a.id
q.save()

for d in detractors:
    a = Answer(text=d, question=q)
    a.save()

I think you need to post your data model and intentions. For one you could just set a default value on the Question model. Aside that though, you have a 1->many or 1->1 relationship but then save the reverse to the other model when you could just use the existing answer FK to the question instead. From a glance you might have a requirements modelling mismatch.

# ? May 23, 2018 19:05

huhu: Feb 24, 2006

I want each question to have only one correct answer and I don't want a boolean on each answer so I thought I'd add an ID that points to the correct answer.

code:

class Question(models.Model):
    text = models.CharField(max_length=300, unique=True)
    correct_answer_id = models.IntegerField(unique=True)


class Answer(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    text = models.IntegerField(unique=False)

# ? May 24, 2018 16:25

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

E: probably missing something obvious here

# ? May 24, 2018 16:39

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

huhu posted:

I want each question to have only one correct answer and I don't want a boolean on each answer so I thought I'd add an ID that points to the correct answer.
code:
class Question(models.Model):
    text = models.CharField(max_length=300, unique=True)
    correct_answer_id = models.IntegerField(unique=True)


class Answer(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    text = models.IntegerField(unique=False)

When you want to relate to a model instance, you use a FK, not an IntegerField.

# ? May 24, 2018 17:41

BaronVonVaderham: Jul 31, 2011; All hail the queen!

huhu posted:

I want each question to have only one correct answer and I don't want a boolean on each answer so I thought I'd add an ID that points to the correct answer.
code:
class Question(models.Model):
    text = models.CharField(max_length=300, unique=True)
    correct_answer_id = models.IntegerField(unique=True)


class Answer(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    text = models.IntegerField(unique=False)

I think the problem is arising in that you have both models pointing at each other in some way, so you end up with your convoluted creation with a placeholder index since both expect the other to exist first. I'm not sure why you don't want a boolean on the Answer model, but that's going to be the correct (read: simplest) solution, at least if we're constrained to leave your model relationships how they are.

I would change it to:

code:

class Question(models.Model):
    text = models.CharField(max_length=300, unique=True)

class Answer(models.Model):[s][/s]
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    text = models.IntegerField(unique=False)
    is_correct_answer = models.BooleanField(default=False)

It can be done without a boolean, I guess, but you have to then set it up as a ManyToMany instead to make the relationship point the other direction:

code:

class Question(models.Model):
    text = models.CharField(max_length=300, unique=True)
    answers = models.ManyToManyField(Answer, related_name="answers")
    correct_answer = models.ForeignKey(Answer)

class Answer(models.Model):
    text = models.IntegerField(unique=False)

I prefer this, since I assume you're constructing some sort of assessment/quiz/test of some kind, where you're probably looping through something like "for question in questions" somewhere. Then you already have your answers handy, especially if you do something like Question.answers.prefetch_related()' so you have everything preloaded.

Better yet, combine the two for what I think is the most logical solution

code:

class Question(models.Model):
    text = models.CharField(max_length=300, unique=True)
    answers = models.ManyToManyField(Answer, related_name="answers")

class Answer(models.Model):
    text = models.IntegerField(unique=False)
    is_correct_answer = models.BooleanField(default=False)

# ? May 24, 2018 18:58

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

Has anyone done anything with geodjango? I've never used it.

I'm thinking about a potential project right now and for some models I might store the users location when they create an object.

Easy enough with a couple of DecimalFields.

I can imagine future iterations of this project wanting to do more like calculate distances...maybe some sort of geo-fencing, etc.

Should I just start out geodjango, or just migrate to it when I need more capabilities?

# ? May 24, 2018 20:39

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

Thermopyle posted:

Should I just start out geodjango, or just migrate to it when I need more capabilities?

I'm in kind of the same boat right now, but with a Java project that we started out with storing GeoJSON in a char field. Now we are migrating it to PostGIS for those additional capabilities, I wish we had just started out with PostGIS to begin with, would have eliminated some of this extra overhead of doing the migration. It's not a huge issue, but I'd say maybe just start out with geodjango if you know that's where it is headed anyways.

I had never heard of geodjango before, looks pretty neat.

# ? May 24, 2018 21:25

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

Super psyched for one of my projects actually, the GIS stuff felt half-baked last time I worked with it (a year or two ago).

# ? May 24, 2018 22:33

epswing: Nov 4, 2003; Soiled Meat

I've got a situation where I want to define a relationship in a superclass.

Say I've got abstract classes

Python code:

class AbstractSchool(models.Model):
    class Meta:
        abstract = True

class AbstractClassroom(models.Model)
    class Meta:
        abstract = True
    school = models.ForeignKey(???, on_delete=models.CASCADE, related_name='classrooms')

And concrete classes:

Python code:

class MySchool(AbstractSchool):
    pass

class MyClassroom(AbstractClassroom):
    pass

I want MyClassroom to have a reference to MySchool, but I want that relationship to live in AbstractClassroom.

I've tried something like this, which sets the school_class in the subclass:

Python code:

class AbstractSchool(models.Model):
    class Meta:
        abstract = True

class AbstractClassroom(models.Model)
    school_class = None
    def get_school_class(self):
        return self.school_class

    class Meta:
        abstract = True
    school = models.ForeignKey(self.get_school_class(), on_delete=models.CASCADE, related_name='classrooms')

class MySchool(AbstractSchool):
    pass

class MyClassroom(AbstractClassroom):
    school_class = MySchool

but I get NameError: name 'self' is not defined on the models.ForeignKey line. I'm browsing the DRF source code because I know they do something like this to set queryset and serializer classes, but I'm not sure how.

Any thoughts/ideas?

# ? Jun 6, 2018 23:19

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

Class variables are class variables, not instance variables so it's not surprising that self didnt work...the variable called self by convention only exists inside methods as the first parameter. You could call it 'instance' or 'foo' or whatever, the name is just a convention, but python passes the instance as the first argument to all methods when you call them.

DRF's queryset and serializer class variables are different because they are never referred to at the level of the class, only inside methods and at that point all class variables have been initialized.

Django model fields are defined at the class level, so you'll never be able to reference something in a ancestor class from within a parent class. It just doesn't exist at that point.

# ? Jun 7, 2018 00:16

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

Here's a neat thing I've been doing.

Using the inspect and ast modules along with django's checks framework to enforce some style and code stuff. Stolen from this guy.

Here's stuff he's enforcing:

quote:

H001: Field has no verbose name.
This is the example we just saw.

H002: Verbose name should use gettext.
Make sure verbose_name is always in the form of verbose_name=_(�text�). If the value is not using gettext it will not be translated.

H003: Words in verbose name must be all upper case or all lower case.
We decided to use only lower case in verbose names. Using lower case texts we were able to reuse more translations. One exception to the rule is acronyms such as API and ETL. The general rule we ended up with is making sure all words are either all lower or all upper case. For example, �etl run� is valid, �ETL run� is also valid, �Etl Run� is not valid.

H004: Help text should use gettext.
Help text is displayed to the user in admin forms and detail views so it should use gettext and be translated.

H005: Model must define class Meta.
The translation of the model name is defined in the model Meta class so every model must have a class Meta.

H006: Model has no verbose name.
Model verbose names are defined in the class Meta and are displayed to the user in the admin so they should be translated.

H007: Model has no verbose name plural.
Plural model names are used in the admin and are displayed to the user so they should be translated.

H008: Must set db_index explicitly on a ForeignKey field.
This must be the most useful check we defined. This check forces the developer to explicitly set db_index on every ForeignKey field. I wrote in the past about how a database index is created implicitly for every foreign key field. By making sure the developer is aware of that and making him decide if an index is required or not, you are left with only the indexes you really need!

We have some abstract model classes that require some configuration by the model that is implementing them. I'm writing some checks to make sure thats done correctly right now.

# ? Jun 7, 2018 22:29

CarForumPoster: Jun 26, 2013; â¡POWERâ¡

Thermopyle posted:

Here's a neat thing I've been doing.

Using the inspect and ast modules along with django's checks framework to enforce some style and code stuff. Stolen from this guy.

Here's stuff he's enforcing:

We have some abstract model classes that require some configuration by the model that is implementing them. I'm writing some checks to make sure thats done correctly right now.

Could you explain this like I am 5? What problem does this solve?

# ? Jun 7, 2018 23:00

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

The same problems it solves when Django itself uses them. Look at Django's list of checks.

I'm not sure if I can describe it more simply than the guy does in the blog post I linked.

Their business requires all fields verbose_text to be translated via gettext. They wrote a check to make sure that is done.

# ? Jun 7, 2018 23:16

huhu: Feb 24, 2006

I've got a form on the frontend where I can insert text, an author, and a category. The POST data for such a creation would look like this, if the author and category already exist in the backend:

code:

[
    {
        "text": "Foo",
        "author": 1
        "category": 1,
    }
]

I'm trying to figure out how to handle what to do if I want to create a new entry in the form where the author or category doesn't exist on the backend already. In that case I'd need to supply the actual string instead of the id. Is there a straightforward way to handle this? All the thoughts I have seem to have bad code smell (checking whether author is an int indicating an id or a string indicating a new entry, adding extra fields to the post, doing one request to create the author and another request to submit the rest of the data)

# ? Jun 9, 2018 03:13

Cock Democracy: Jan 1, 2003; Now that is the finest piece of chilean sea bass I have ever smelled

huhu posted:

Is there a straightforward way to handle this? All the thoughts I have seem to have bad code smell (checking whether author is an int indicating an id or a string indicating a new entry, adding extra fields to the post, doing one request to create the author and another request to submit the rest of the data)

I would have it pass the strings, regardless of if it's new or existing. Then your view method can try to look up the records by name and create them if necessary. Make sure to use a unique constraint on the author and category name fields.

# ? Jun 9, 2018 21:00

epswing: Nov 4, 2003; Soiled Meat

I've noticed when dumping SQL queries to a log file that all my queries appear to be duplicated.

For example, in a single request:

quote:

[2018-06-11 16:42:16] DEBUG utils (0.001) SELECT "django_session"."session_key", "django_session"."...
[2018-06-11 16:42:16] DEBUG utils (0.001) SELECT "django_session"."session_key", "django_session"."...
[2018-06-11 16:42:16] DEBUG utils (0.001) SELECT "auth_user"."id", "auth_user"."password", "auth_us...
[2018-06-11 16:42:16] DEBUG utils (0.001) SELECT "auth_user"."id", "auth_user"."password", "auth_us...
[2018-06-11 16:42:16] DEBUG utils (0.000) SELECT "mservice_client"."id", "mservice_client"."name" F...
[2018-06-11 16:42:16] DEBUG utils (0.000) SELECT "mservice_client"."id", "mservice_client"."name" F...
[2018-06-11 16:42:16] DEBUG utils (0.001) SELECT "mservice_servicereport"."id", "mservice_servicere...
[2018-06-11 16:42:16] DEBUG utils (0.001) SELECT "mservice_servicereport"."id", "mservice_servicere...

Any idea what could be causing this? I'm using Django 1.11, and Python 2.7, with the dev server talking to SQLite. I'm sure I'm not actually making all these queries twice each.

# ? Jun 11, 2018 21:45

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

When I see that it's always a logging config issue.

Like logging in a root logger and in one of the Django-specific loggers.

# ? Jun 11, 2018 21:52

Adbot: ADBOT LOVES YOU

# ? May 31, 2024 23:20

epswing: Nov 4, 2003; Soiled Meat

Thermopyle posted:

When I see that it's always a logging config issue.

Like logging in a root logger and in one of the Django-specific loggers.

Right, I wondered if it was maybe just a logging issue. Is it because I've got both 'django' and 'django.db.backends'? Should one of them not propagate? My 'loggers' looks like this

code:

    'loggers': {
        'django': {
            'level': 'INFO',
            'handlers': ['file', 'mail_admins'],
            'propagate': True,
        },
        'django.db.backends': {
            'level': 'DEBUG',
            'handlers': ['file'],
            'propagate': True,
        },
        'django_crontab.crontab': {
            'handlers': ['file', 'mail_admins'],
            'level': 'INFO',
            'propagate': True,
        },
        'myapp': {
            'level': 'INFO',
            'handlers': ['file', 'mail_admins'],
            'propagate': True,
        },

# ? Jun 11, 2018 22:00

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

«‹›122 »