ForeignKey in Inline generates lots of queries
I posted this to Django users, but didn't get a response. I'd like to help
to resolve this issue if at all possible.
Previous post:
I have the Django admin configured with a TabularInline, and the inline
model has a ForeignKey reference to a third model. Every row in the inline
generates a new query to fetch all of the instances of the third model.
Here's an overview of my code:
# models.py
> from django.db import models
>
> class ExampleParent(models.Model):
>
> def __unicode__(self):
> return u'Example Parent: %s' % self.id
>
> class ExampleInline(models.Model):
> parent = models.ForeignKey('ExampleParent')
> child = models.ForeignKey('ExampleChild')
>
> def __unicode__(self):
> return u'Example Inline: %s' % self.id
>
> class ExampleChild(models.Model):
>
> def __unicode__(self):
> return u'Example Child: %s' % self.id
>
# admin.py
> from django.contrib import admin
>
> from admin_issue.example_problem.models import (ExampleParent,
> ExampleInline)
>
> class ExampleInlineInline(admin.TabularInline):
> model = ExampleInline
>
> class ExampleParentAdmin(admin.ModelAdmin):
> inlines = [
> ExampleInlineInline
> ]
>
> admin.site.register(ExampleParent, ExampleParentAdmin)
>
If you create a bunch of ExampleInlines that reference and ExampleParent,
then go to that instance in the admin, you get QUERY = u'SELECT
"example_problem_examplechild"."id" FROM "example_problem_examplechild"' -
PARAMS = () for every ExampleInline referenced.
Shouldn't that query be cached by Django? Is that expected behavior? Is
there a way to force Django to use the cache for subsequent inlines?
I'm also experiencing a similar problem with a ManyToMany field. (But it
seems to generate even more queries that the ForeignKey)
Any help on this issue would be most appreciated.
Thanks,
John P.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/139e1577-86b2-4d96-9da9-c62d3dba2c75%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
GSOC 2014 Proposal
I wanted to work on improving the djangobook by making certain applications based on every module of the djangobook which will help a beginner to get along with various features Django. Example:use of JSON API in the Web Framework Django Sample apps are in my Repository: *https://github.com/deebee07* Movie_db and TemplateProject being some samples I am currently working with Khan Academy,California as an intern from IIT Bombay -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2534dac7-c54a-4340-a9ad-d854b00a5cc8%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
flush (sqlflush) command and multiple databases
Hey! I think I've found a bug in flush command, but I'm not sure (maybe I don't understand Django ethos?) so I'm writing here. I have multiple databases (PostgreSQL) and multiple apps in my projects. I'm using Django v1.5.1. Models are routed by my specific database router, so some apps are connected to database A, some to db B, and so on... I'm trying to flush all databases for tests (calling flush for each database separately) and every sqlflush fails. Why? Because django.core.management.sql.sql_flush is called with only_django with only_existing=True that produces truncate sql for really existing tables in specified database (via --database argument), which is ok, BUT next step is a resetting ALL sequences for ALL models fetched from connection.introspection.sequence_list(). And that SQL simply fails. Generated SQL for database A contains sequences for ALL tables and ALL defined databases, which simply fails. I've tried to filter tables in sequence_list(), which is not good solution, but enough to ensure. And guess what? - flush command passed without errors. Have you ever found that issue? Does anyone is using multiple databases with postgres backend (probably there is no issue with mysql)? Or maybe I'm doing something wrong? Kind Regards, Marcin -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7f52c7ef-013b-4390-bf55-a57ad96e1c9d%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
GSOC 2014 Project Proposal
I am into my last year of graduation and I am currently an intern in Khan Academy ,Foundation for Learning Equality from IIT Bombay .I have been developing working with Django for the same *Title*: Building basic Web Frameworks for each module of Django Book for the beginners I have prepared sample code which uses a JSON file and converts it in to a hierarchial topic tree so that a basic developer with the knowledge of HTML,CSS can easily understand with the documentation to each of the app prepared the interactive way to code in Django *Sample Code* Git Repo: https://github.com/deebee07 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/938d29f3-70cf-4587-8084-6f153a394cb9%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: The unsettings project
Hi, I'd like to describe how we've solved the per-package settings issue at our company. Here's a little source code example: https://gist.github.com/wkornewald/9109270 Every Python package defines a module with a Config instance and then sets default settings on it. Instead of defining settings as global variables in a module you import all packages' config instances and set custom settings. Settings which require imports can be configured by using set_lazy() and passing lambdas/functions which do those imports on-demand. The lazy function's return value is cached. There's also a sandbox mechanism where you can do: with config: config.set(debug=True) # all code will now think we're in debug mode # and here we're back to the previous setting Sandboxing can be useful for unit tests. Anyway, please take a look at the code example in the link above. If you need more fine-grained control, you can of course also attach config instances to individual objects instead of packages. So, what do you think? Greetings, Waldemar Kornewald On Sunday, February 16, 2014 11:55:24 AM UTC+1, Aymeric Augustin wrote: > > Hi Schuyler, > > On 14 févr. 2014, at 15:18, Schuyler Duveen > > wrote: > > TLDR: Django modules should work as libraries (e.g. ORM, mail, etc). > "from django.conf import settings" bootstrap undermines this. > > > My use-case is Django's awesome (yes, I know opinions differ), > simple-to-use ORM. > > > For the ORM, settings aren't the primary concern. The biggest problem is > setting up relations between models. This needs to be done at some point > before you start using models. > > Before Django 1.7, the app cache took care of that at some ill-specified > and project-dependant point. During the app-loading refactor, we recognized > that such an important step couldn’t be left to chance and we introduced an > explicit bootstrap, `django.setup()`. > > Given the current implementation of `django.setup()`, it seems possible to > inject the settings there in another form that a Python module, if that’s > what you’re after. See > https://github.com/django/django/blob/master/django/__init__.py#L11-L21. > > It seems to me that you haven’t attacked the right problem for what you’re > describing as your primary use case. (That’s why I’ve been asking for a > mailing-list discussion since September.) > > Besides, you need a plan to replace `django.setup()`. > > For the first trial at this approach, we tried out utils.timezone: > > https://github.com/SlashRoot/django/blob/33c49245032115cf3fd6534d5a55313435419ffb/django/utils/timezone.py#L302 > > and it seemed to have worked, so we moved on to django.core.mail, and > other modules. > > > All the discourse around unsettings is based on the assumption that it’s > an incremental improvement that may provide some other benefits in the > future. > > However, the current results aren’t looking so good to me: > - The new APIs are weird: functions end up with additional keywords > arguments purely based on their implementation. This isn’t a good way to > design and API. (I assume that the goal of unsettings is to make these APIs > public.) > - It makes the code more complex: every contributor to Django will have to > learn a new way to inject settings into functions. In order to keep the > barrier to contributing to Django low, I’m not fond of such idiosyncrasies. > > Also, benefits still look quite hypothetical, if not theoretical. I’m > worried about beginning a path without a convincing explanation of why it > isn’t a dead-end. In the past, we’ve hit dead-ends on projects much better > planned that this one, eg. mitsuhiko’s “template compilation” GSoC. > > That makes me -1 on the concept for now. I don’t believe it beats the > status quo. To change my vote, I would need: > - a description of how you plan to deal with django.setup() — it seems > more complicated than dealing with settings; > - an explanation of what comes after we replace every “settings.FOO” with > “@unsettings(FOO=…)”; > - some thoughts of why we’re comfortable maintaining the resulting public > APIs in the long term. > > I have much more to say but I’ve tried to summarize my thoughts in this > email. I hope this helps. > > -- > Aymeric. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3f40c711-1b71-406a-acf5-79ca78161c49%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
