Re: [Choose Database based on geolocalization]
On 03/09/2015 01:58 AM, Russell Keith-Magee wrote: > Yes, DB Routers support hints. How are you planning to inject those > hints into the router? Router arguments aren't exposed to the end user > when you do a query - they're automatically generated by the query, > and only include details about related objects in the query. A quick and draft thought would be to have a middleware that manipulates the ConnectionRouter class, which is instantiated when making database queries. But, before looking at the implementation details, maybe we should first think if it would be useful in general as a feature to pass a hint for the HTTP request to the DB routers. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54FD585A.5000302%40yahoo.gr. For more options, visit https://groups.google.com/d/optout.
Re: [Choose Database based on geolocalization]
On 03/08/2015 01:42 AM, Russell Keith-Magee wrote: > Hi Xina, > > The short answer is "not easily, and not within Django". > > Django's DB Routers don't contain any detail about the request, so > there's no ability to geolocated the requesting IP for routing > purposes. For the record, this is because Django is a general purpose > toolkit - there's no guarantee that a request to access the DB has > come as a result of a HTTP request - it might come from a standalone > script, which won't have an IP address. > Django's DB routers have the notion of 'hints'. So, theoretically, a hint with the HTTP request object could be passed to a db router (when access to a database comes as a result of an HTTP request) or not passed at all (if the database request is triggered by other means, e.g. a standalone script). I am not saying that Xina's use case would be served better with such an implementation though. Just pointing out that, in theory, there should be no inherent restriction in Django supporting this. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54FC4B6C.4040302%40yahoo.gr. For more options, visit https://groups.google.com/d/optout.
Re: Optimizing admin change view with inlines
Hello Collin,
On 12/29/14 07:25, Collin Anderson wrote:
> Hi Petros,
>
> I think the raw_id_fields still display the __str__/__unicode__ of the
> selected object so therefore need to get queried. I wonder if
> select_related would possibly help?
>
I do have select_related in the queryset (look at the last version of
ExampleBInline in my previous post).
The thing is that if the same fields that are included in raw_id_fields
are also included in readonly_fields, the queries are reduced
dramatically, despite the fact that the same amount of information is
displayed in both cases. __str__()/__unicode__ is still called when the
fields are in readonly_fields, so it is really very strange why there is
difference between adding and commenting out the readonly_fields line.
Very strange...
> Collin
>
> On Wednesday, December 24, 2014 5:53:02 AM UTC-6, Ernest0x wrote:
>
> On 12/24/14 13:30, 'Petros Moisiadis' via Django users wrote:
> > On 12/23/14 19:13, 'Petros Moisiadis' via Django users wrote:
> >> Hello people :)
> >>
> >> I am struggling with optimizing an admin with inlines which
> causes too
> >> many database requests.
> >>
> >> My model structure is like this:
> >>
> >> class ExampleA(models.Model):
> >> ...
> >>
> >> class ExampleB(models.Model):
> >> aexample = models.ForeignKey('ExampleA',
> related_name='bexamples')
> >> cexample = models.ForeignKey('ExampleC')
> >> dexample = models.ForeignKey('ExampleD')
> >> eexample = models.ForeignKey('ExampleE')
> >> ...
> >>
> >> class ExampleC(models.Model):
> >> ...
> >>
> >> class ExampleD(models.Model):
> >> ...
> >>
> >> class ExampleE(models.Model):
> >> ...
> >>
> >> The admin classes:
> >>
> >> class ExampleBInline(admin.StackedInline):
> >> model = ExampleB
> >> extra = 0
> >>
> >> class ExampleAAdmin(admin.ModelAdmin):
> >> inlines = [ExampleBInline]
> >>
> >> admin.site.register(ExampleA, ExampleAAdmin)
> >>
> >> As I can see with django-debug-toolbar, when rendering the admin
> >> template for the inline formset with the forms for ExampleB
> objects, a
> >> new db request is sent to db server for each related field of each
> >> ExampleB object. Particularly, I am seeing a lot of queries
> like these:
> >>
> >> SELECT ••• FROM `examplec` WHERE `examplec`.`id` = 1 LIMIT 21
> >> SELECT ••• FROM `examplee` WHERE `examplee`.`id` = 2 LIMIT 21
> >> SELECT ••• FROM `examplec` WHERE `examplec`.`id` = 2 LIMIT 21
> >> SELECT ••• FROM `exampled` WHERE `exampled`.`id` = 2 LIMIT 21
> >> SELECT ••• FROM `examplee` WHERE `examplee`.`id` = 3 LIMIT 21
> >>
> >> The template context is this (I am using grappelli):
> >>
> >> 21{% if field.is_readonly %}
> >> 22{{
> >> field.contents|linebreaksbr }}
> >> 23{% else %}
> >> the marked line => 24{{ field.field }}
> >> 25{% endif %}
> >> 26{% endif %}
> >> 27{% if line.fields|length_is:'1' %}{{
> >> line.errors }}{% endif %}
> >>
> >>
> >> I have tried the following optimizations:
> >>
> >> First try:
> >>
> >> class ExampleAAdmin(admin.ModelAdmin):
> >> inlines = [ExampleBInline]
> >>
> >> def get_queryset(self, request):
> >> qs = super(ExampleAAdmin, self).get_queryset(request)
> >> return qs.prefetch_related('bexamples',
> >> 'bexamples__cexample', 'bexamples__dexample',
> 'bexamples__example')
> >>
> >> Second try:
> >>
> >> class ExampleBInline(admin.StackedInline):
> >> model = ExampleB
> >> extra = 0
&g
Re: Optimizing admin change view with inlines
On 12/24/14 13:30, 'Petros Moisiadis' via Django users wrote:
> On 12/23/14 19:13, 'Petros Moisiadis' via Django users wrote:
>> Hello people :)
>>
>> I am struggling with optimizing an admin with inlines which causes too
>> many database requests.
>>
>> My model structure is like this:
>>
>> class ExampleA(models.Model):
>> ...
>>
>> class ExampleB(models.Model):
>> aexample = models.ForeignKey('ExampleA', related_name='bexamples')
>> cexample = models.ForeignKey('ExampleC')
>> dexample = models.ForeignKey('ExampleD')
>> eexample = models.ForeignKey('ExampleE')
>> ...
>>
>> class ExampleC(models.Model):
>> ...
>>
>> class ExampleD(models.Model):
>> ...
>>
>> class ExampleE(models.Model):
>> ...
>>
>> The admin classes:
>>
>> class ExampleBInline(admin.StackedInline):
>> model = ExampleB
>> extra = 0
>>
>> class ExampleAAdmin(admin.ModelAdmin):
>> inlines = [ExampleBInline]
>>
>> admin.site.register(ExampleA, ExampleAAdmin)
>>
>> As I can see with django-debug-toolbar, when rendering the admin
>> template for the inline formset with the forms for ExampleB objects, a
>> new db request is sent to db server for each related field of each
>> ExampleB object. Particularly, I am seeing a lot of queries like these:
>>
>> SELECT ••• FROM `examplec` WHERE `examplec`.`id` = 1 LIMIT 21
>> SELECT ••• FROM `examplee` WHERE `examplee`.`id` = 2 LIMIT 21
>> SELECT ••• FROM `examplec` WHERE `examplec`.`id` = 2 LIMIT 21
>> SELECT ••• FROM `exampled` WHERE `exampled`.`id` = 2 LIMIT 21
>> SELECT ••• FROM `examplee` WHERE `examplee`.`id` = 3 LIMIT 21
>>
>> The template context is this (I am using grappelli):
>>
>> 21{% if field.is_readonly %}
>> 22{{
>> field.contents|linebreaksbr }}
>> 23{% else %}
>> the marked line => 24{{ field.field }}
>> 25{% endif %}
>> 26{% endif %}
>> 27{% if line.fields|length_is:'1' %}{{
>> line.errors }}{% endif %}
>>
>>
>> I have tried the following optimizations:
>>
>> First try:
>>
>> class ExampleAAdmin(admin.ModelAdmin):
>> inlines = [ExampleBInline]
>>
>> def get_queryset(self, request):
>> qs = super(ExampleAAdmin, self).get_queryset(request)
>> return qs.prefetch_related('bexamples',
>> 'bexamples__cexample', 'bexamples__dexample', 'bexamples__example')
>>
>> Second try:
>>
>> class ExampleBInline(admin.StackedInline):
>> model = ExampleB
>> extra = 0
>>
>> def get_queryset(self, request):
>> qs = super(ExampleInline, self).get_queryset(request)
>> return qs.select_related('cexample', 'dexample', 'eexample')
>>
>> Third try:
>>
>> class BaseExampleBFormSet(BaseInlineFormSet):
>> def __init__(self, *args, **kwargs):
>> super(BaseExampleBFormSet, self).__init__(*args, **kwargs)
>> qs = self.queryset
>> self.queryset = qs.select_related('cexample', 'dexample',
>> 'eexample')
>>
>> ExampleBFormSet = inlineformset_factory(ExampleA, ExampleB,
>> formset=BaseExampleBFormSet)
>>
>> class ExampleBInline(admin.StackedInline):
>> model = ExampleB
>> extra = 0
>> formset = ExampleBFormSet
>>
>> Unfortunately, none of the above works.
>>
>> So, I would be really grateful if anyone could help on this by giving
>> any hint or pointing out what could be possibly missing. Or, could I
>> have hit a restriction of django admin's internals?
>>
>> Thank you in advance,
>>
>> Petros
>>
> Hello again,
>
> I would like to clarify that the big number of db requests is not caused
> by fetching all the objects for the related model to populace select
> boxes for the related fields in the line, as it is often the case. To
> avoid that, I have included the related fields in raw_id_fields. I have
> also used grappelli's convenient
Re: Optimizing admin change view with inlines
On 12/23/14 19:13, 'Petros Moisiadis' via Django users wrote:
> Hello people :)
>
> I am struggling with optimizing an admin with inlines which causes too
> many database requests.
>
> My model structure is like this:
>
> class ExampleA(models.Model):
> ...
>
> class ExampleB(models.Model):
> aexample = models.ForeignKey('ExampleA', related_name='bexamples')
> cexample = models.ForeignKey('ExampleC')
> dexample = models.ForeignKey('ExampleD')
> eexample = models.ForeignKey('ExampleE')
> ...
>
> class ExampleC(models.Model):
> ...
>
> class ExampleD(models.Model):
> ...
>
> class ExampleE(models.Model):
> ...
>
> The admin classes:
>
> class ExampleBInline(admin.StackedInline):
> model = ExampleB
> extra = 0
>
> class ExampleAAdmin(admin.ModelAdmin):
> inlines = [ExampleBInline]
>
> admin.site.register(ExampleA, ExampleAAdmin)
>
> As I can see with django-debug-toolbar, when rendering the admin
> template for the inline formset with the forms for ExampleB objects, a
> new db request is sent to db server for each related field of each
> ExampleB object. Particularly, I am seeing a lot of queries like these:
>
> SELECT ••• FROM `examplec` WHERE `examplec`.`id` = 1 LIMIT 21
> SELECT ••• FROM `examplee` WHERE `examplee`.`id` = 2 LIMIT 21
> SELECT ••• FROM `examplec` WHERE `examplec`.`id` = 2 LIMIT 21
> SELECT ••• FROM `exampled` WHERE `exampled`.`id` = 2 LIMIT 21
> SELECT ••• FROM `examplee` WHERE `examplee`.`id` = 3 LIMIT 21
>
> The template context is this (I am using grappelli):
>
> 21{% if field.is_readonly %}
> 22{{
> field.contents|linebreaksbr }}
> 23{% else %}
> the marked line => 24{{ field.field }}
> 25{% endif %}
> 26{% endif %}
> 27{% if line.fields|length_is:'1' %}{{
> line.errors }}{% endif %}
>
>
> I have tried the following optimizations:
>
> First try:
>
> class ExampleAAdmin(admin.ModelAdmin):
> inlines = [ExampleBInline]
>
> def get_queryset(self, request):
> qs = super(ExampleAAdmin, self).get_queryset(request)
> return qs.prefetch_related('bexamples',
> 'bexamples__cexample', 'bexamples__dexample', 'bexamples__example')
>
> Second try:
>
> class ExampleBInline(admin.StackedInline):
> model = ExampleB
> extra = 0
>
> def get_queryset(self, request):
> qs = super(ExampleInline, self).get_queryset(request)
> return qs.select_related('cexample', 'dexample', 'eexample')
>
> Third try:
>
> class BaseExampleBFormSet(BaseInlineFormSet):
> def __init__(self, *args, **kwargs):
> super(BaseExampleBFormSet, self).__init__(*args, **kwargs)
> qs = self.queryset
> self.queryset = qs.select_related('cexample', 'dexample',
> 'eexample')
>
> ExampleBFormSet = inlineformset_factory(ExampleA, ExampleB,
> formset=BaseExampleBFormSet)
>
> class ExampleBInline(admin.StackedInline):
> model = ExampleB
> extra = 0
> formset = ExampleBFormSet
>
> Unfortunately, none of the above works.
>
> So, I would be really grateful if anyone could help on this by giving
> any hint or pointing out what could be possibly missing. Or, could I
> have hit a restriction of django admin's internals?
>
> Thank you in advance,
>
> Petros
>
Hello again,
I would like to clarify that the big number of db requests is not caused
by fetching all the objects for the related model to populace select
boxes for the related fields in the line, as it is often the case. To
avoid that, I have included the related fields in raw_id_fields. I have
also used grappelli's convenient autocomplete lookup feature, but that
does not add extra queries. So, the inline class actually looks like this:
class ExampleBInline(admin.StackedInline):
model = ExampleB
extra = 0
raw_id_fields = ['cexample', 'dexample', 'eexample']
autocomplete_lookup_fields = {
'fk': ['cexample', 'dexample', 'example'],
}
The only optimization that works is adding the related fields in
readonly_fields in combination with a queryset changing
Optimizing admin change view with inlines
Hello people :)
I am struggling with optimizing an admin with inlines which causes too
many database requests.
My model structure is like this:
class ExampleA(models.Model):
...
class ExampleB(models.Model):
aexample = models.ForeignKey('ExampleA', related_name='bexamples')
cexample = models.ForeignKey('ExampleC')
dexample = models.ForeignKey('ExampleD')
eexample = models.ForeignKey('ExampleE')
...
class ExampleC(models.Model):
...
class ExampleD(models.Model):
...
class ExampleE(models.Model):
...
The admin classes:
class ExampleBInline(admin.StackedInline):
model = ExampleB
extra = 0
class ExampleAAdmin(admin.ModelAdmin):
inlines = [ExampleBInline]
admin.site.register(ExampleA, ExampleAAdmin)
As I can see with django-debug-toolbar, when rendering the admin
template for the inline formset with the forms for ExampleB objects, a
new db request is sent to db server for each related field of each
ExampleB object. Particularly, I am seeing a lot of queries like these:
SELECT ••• FROM `examplec` WHERE `examplec`.`id` = 1 LIMIT 21
SELECT ••• FROM `examplee` WHERE `examplee`.`id` = 2 LIMIT 21
SELECT ••• FROM `examplec` WHERE `examplec`.`id` = 2 LIMIT 21
SELECT ••• FROM `exampled` WHERE `exampled`.`id` = 2 LIMIT 21
SELECT ••• FROM `examplee` WHERE `examplee`.`id` = 3 LIMIT 21
The template context is this (I am using grappelli):
21{% if field.is_readonly %}
22{{
field.contents|linebreaksbr }}
23{% else %}
the marked line => 24{{ field.field }}
25{% endif %}
26{% endif %}
27{% if line.fields|length_is:'1' %}{{
line.errors }}{% endif %}
I have tried the following optimizations:
First try:
class ExampleAAdmin(admin.ModelAdmin):
inlines = [ExampleBInline]
def get_queryset(self, request):
qs = super(ExampleAAdmin, self).get_queryset(request)
return qs.prefetch_related('bexamples',
'bexamples__cexample', 'bexamples__dexample', 'bexamples__example')
Second try:
class ExampleBInline(admin.StackedInline):
model = ExampleB
extra = 0
def get_queryset(self, request):
qs = super(ExampleInline, self).get_queryset(request)
return qs.select_related('cexample', 'dexample', 'eexample')
Third try:
class BaseExampleBFormSet(BaseInlineFormSet):
def __init__(self, *args, **kwargs):
super(BaseExampleBFormSet, self).__init__(*args, **kwargs)
qs = self.queryset
self.queryset = qs.select_related('cexample', 'dexample',
'eexample')
ExampleBFormSet = inlineformset_factory(ExampleA, ExampleB,
formset=BaseExampleBFormSet)
class ExampleBInline(admin.StackedInline):
model = ExampleB
extra = 0
formset = ExampleBFormSet
Unfortunately, none of the above works.
So, I would be really grateful if anyone could help on this by giving
any hint or pointing out what could be possibly missing. Or, could I
have hit a restriction of django admin's internals?
Thank you in advance,
Petros
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/5499A2A1.3040403%40yahoo.gr.
For more options, visit https://groups.google.com/d/optout.
