Cheers,
Simon
[0] https://www.postgresql.org/message-id/21634.1160151...@sss.pgh.pa.us
Le mercredi 23 septembre 2020 à 12:15:35 UTC-4, d.ivan...@distillery.com a
écrit :
> Hello.
> I just wanted to know, whether I run into a bug, and whether I should
> report it.
>
> Normally
Hello.
I just wanted to know, whether I run into a bug, and whether I should
report it.
Normally select_for_update and select_related try to lock all affected rows
in all tables. One can specify "of" for select_for_update to limit tables
to lock (to prevent locking nullable
ot of users) I will have an issue with
postgres queries so I wonder what is the best way to add
prefetch_related and select_related options to Member queries so that
they exist in the request.user.
I can't find in the django code where the request is populated with the
User model, but I
This is an insanely old thread, but I couldn't find any updates so was
curious if anyone had advice on implementing select_related with a
RawQuerySet? It seems prefetch_related() works just fine.
On Friday, March 2, 2012 at 11:22:52 AM UTC-8, akaariai wrote:
>
> On Friday, March 2
Hi,
model.many_to_many_atribute.all()
model.many_to_many_atribute.find(name="carl")
El lun., 24 jun. 2019 a las 19:18, Charlotte Wood (<
charlotte.w...@epiccharterschools.org>) escribió:
> HELP!
>
> Do ManyToManyFields just not print?
>
> I see them in my form selection.
>
> Everything works fi
HELP!
Do ManyToManyFields just not print?
I see them in my form selection.
Everything works fine, but when I try to put the linked item on a list
form, i get: project.model.none for the value. I cannot figure out how to
make all the values print. HELP! PLEASE!!
--
You received this messa
On Monday, November 6, 2017 at 9:36:11 PM UTC+1, Matthew Pava wrote:
>
> Is it really that bad? Maybe I’m missing something in your situation.
>
Ooooh, it isn't really. I incorrectly assumed that the query would perform
like having an implicit DISTINCT(device.id). But it does in fact return
abs
om] On
Behalf Of Samuel Abels
Sent: Monday, November 6, 2017 2:22 PM
To: Django users
Subject: Re: Equivalent of multi-table JOIN (another post on reverse
select_related)
On Monday, November 6, 2017 at 9:15:09 PM UTC+1, Matthew Pava wrote:
Maybe you are expecting too much from the user interfa
On Monday, November 6, 2017 at 9:15:09 PM UTC+1, Matthew Pava wrote:
>
> Maybe you are expecting too much from the user interface. Shouldn’t you
> at least request from the user what primary object you are looking for?
>
The primary model is always that one that is closest to "device"; step 2
roups.com [mailto:django-users@googlegroups.com] On
Behalf Of Samuel Abels
Sent: Monday, November 6, 2017 1:59 PM
To: Django users
Subject: Re: Equivalent of multi-table JOIN (another post on reverse
select_related)
Thanks, I have seen that and plan to use it, but for this particular feature I
of multi-table JOIN (another post on reverse
> select_related)
>
>
>
> I am working on a reporting feature that allows users for querying
> arbitrary models and fields, and present the result as a table. For
> example, consider the following object
users
Subject: Equivalent of multi-table JOIN (another post on reverse select_related)
I am working on a reporting feature that allows users for querying arbitrary
models and fields, and present the result as a table. For example, consider the
following object model:
Package
|
v
Device
o avoid the raw SQL. I considered the following
options:
- Using Device.objects.select_related() does not work, because Device has a
1:n relation to Package (and also to Unit), which Django's select_related()
does not support.
- Using prefetch_related() does not work, because it prefetches
x27;s just the raw results. Without iterator(), these raw results are
immediately converted to model instances, and related objects that have
been loaded with select_related() or prefetch_related are converted to
model instances as well. This can cause a spike in CPU and memory usage.
When using ite
Hi,
Thanks for your response. But I have observed the following:
Without Iterator: It takes a bit of a time before the for loop is executed
and also the CPU spikes up during that period and so does the Memory -
which implies the DB is accessed to fetch all the results.
With iterator: The for l
I think the benefit of using the iterator is best explained by an example:
Without iterator:
You loop through the queryset, using each item for whatever you're doing.
As you do this, all the items are now in your local scope, using up RAM.
If, after the loop, you should want to loop through the
Hi,
Could someone please let me know what the implications of Django queryset
iterator on select_related and prefetch_related?
Also, I am still not quite clear on the concept of iterator which I
understand returns a Generator. Whenever a for loop is run on the
Generator, the DB is queried
Hi Gilad,
The `parent_link` option can only be used if the model the o2o field is
pointing to is a direct base of the model it's attached to. From what I
understand `select_related` simply ignores `parent_link` fields since it
assumes it's pointing to a MTI parent table which are
not abstract.
2. Each of the models have their own real tables.
3. Not using model inheritance because I want the parent_link field to
be called "id" (as the db column), and Django doesn't allow hiding fields
(with the same name).
Given all that, using select_related(&
Small correction, prefetch_related doesn't issue any JOIN unless a is query
with a select_related is specified with a Prefetch object.
Simon
Le jeudi 21 mai 2015 17:53:30 UTC-4, Ash Christopher a écrit :
>
> Hi David,
>
> *select_related* does a JOIN under the hood, and you
Hi David,
*select_related* does a JOIN under the hood, and you can't do
cross-database joins in the databases supported by Django. For
prefetch_related, there is no way out of the box to perform a
cross-database join in Python (which is what prefetch_related is doing) but
perhaps there is
Dear List,
I came about conflicting information (to my mind) concerning the use of
select_related() and prefetch_related().
My question is whether you can combine select_related() and
prefetch_related() with sharding techniques. If so, how are you doing it?
Background:
I was watching various
I have problems with the use of select_related.
I have two models where one model keeps language independent data, and
the other keeps translations in various languages.
class Model()
company = ForeignKey(Company, null=True, blank=True)
def getCompanyName(self):
return
Ok please excuse my message, I found there was a comma missing somewhere
betwen different select_related parameters.
J
I have problems with the use of select_related.
I have two models where one model keeps language independent data, and
the other keeps translations in various languages
4, 2014 11:59:08 AM UTC-5, Zach Snow wrote:
>
> Hi there. I'm running into some strange behavior when using `defer` with
> `select_related` and I wanted to find out if I'm simply misunderstanding
> what should be going on, or if indeed I have stumbled onto a bug.
>
> Summary:
Hi there. I'm running into some strange behavior when using `defer` with
`select_related` and I wanted to find out if I'm simply misunderstanding
what should be going on, or if indeed I have stumbled onto a bug.
Summary: Using `defer` on a table that has been re-included in a
thanks for your input fellas, solved my problem.
--
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
Instead of spoon-feeding you, I would recommend using DDT and check out the
query that is generated and whether if it satisfies your use-case. By this,
you will know how exactly select_related works and also the number of
queries that gets fired in the page and what happens once you use this.
On
Hi. select_related is used for folloing foreign keys. So if u have, say,
product and its producer field in it u can do smth like:
Product.objects.select_related('producer') and in ur templates accessing
product.producer won't hit the database.
Notice that here we have a relation
Okay, I'm a little confused here about using select_ralated...
Can you only run select_related on a table that HAS a foreign key not a
table that IS a foreign key?
What if I want to go:
SELECT * FROM product LEFT JOIN review on product.id = review.product_id
LEFT JOIN comments ON produ
Hi, I am using select_related in a loop in order to reduce database hits.
The weird thing is that I get a different result set when using
select_related();
This is not the actual code, but a simple example that illustrates the
problem:
>>> rr =
> RouteTableRangeProvider.ob
Hi,
I have the following query:
Buch = Buchung.objects.filter(Produkt = int(POSTvalues['Produkt']))
Later I'm using stuff like:
Buch.Produkt.Bestell_Nr
To speed things up i wan't to use select_related() on the query but no mather
where I add it if I add it i get 0
Okay, I see now. Can't do that. Never mind.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/5S6X8Bpl0kAJ.
To post to this group, send email to django-use
Does use_for_related_fields work with ManyToMany fields? From the source,
it looks like it does not. Can anyone confirm that?
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/
I have a custom manager class that has use_for_related_field set to true,
and I set it to be the default manager in my model. But when I make a
query using select_related on the related field, I seem to get a plain
queryset, not my custom one. Here's a quick sketch of what I'm doi
at 6:02 AM, Yo-Yo Ma wrote:
> Given a model ``Employee`` with a foreign key ``company`` pointing to a
> model called ``Company``, would the following example lock both the
> ``Employee`` and ``Company`` rows that were selected?
>
> employee =
> Employee.objects.select_for_
Given a model ``Employee`` with a foreign key ``company`` pointing to a
model called ``Company``, would the following example lock both the
``Employee`` and ``Company`` rows that were selected?
employee =
Employee.objects.select_for_update().select_related('company').get(pk=1)
Or,
ue of a foreign key
> on the model, and I need to join to the related table in order to
> filter the results.
>
> Having generated the queryset, I then want to make a dictionary of {
> foreign_key_object : model_object }. So I have this working, but I
> cannot use select_rela
filter the results.
Having generated the queryset, I then want to make a dictionary of {
foreign_key_object : model_object }. So I have this working, but I
cannot use select_related() with a RawQuerySet, and so this runs N+1
queries, where N is the number of distinct foreign keys.
Here is some code, w
therapy resident__lname
> resident__fname resident__room resident__payor'.split())
>
> facility = models.Facility.objects.get(pk='xx')
>
> queryset = models.Order.objects.filter(facility=facility)
>
> queryset = queryset.filter(therapy='OT&#
queryset = queryset.filter(therapy='OT').select_related()
#sometimes want all, othertimes just one type
unscheduled = [x for x in queryset if not x.schedule_set.all()]
for u in unscheduled: print u.schedule_set.all(), u.__dict__
--
You received this message because
Thank you Sebastien and Daniel for your replies.
Daniel, I am new to Django and Python which is why it's taking a while
to get used to it.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googleg
On Monday, 19 September 2011 10:53:18 UTC+1, David wrote:
>
> Hi Daniel
>
> Having installed Django debug toolbar it looks like select_related is
> only performing one level of relation finding as opposed to following
> relationships through to their conclusion.
company?
This is my select_related line:
a = Company.objects.select_related().get(pk=pk)
Regarding your reply (1.) because there are no FK's in the company
table I had assumed that Django must be using reverse relations to
access Person. Is that not the case?
Yes, it is. But
OK I think I know why, and is this correct please?
class Company
class Person
class Purchase
Person is related to Company by a FK in Person called company. Class
Purchase is related to Person by a FK in Person called FK - not
company.
Therefore is it correct that Django's ORM only pursues comp
Even when specifying depth in the select_related line I cannot get
Django's ORM to look past one level below Company.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googl
Hi Daniel
Having installed Django debug toolbar it looks like select_related is
only performing one level of relation finding as opposed to following
relationships through to their conclusion.
--
You received this message because you are subscribed to the Google Groups
"Django users"
On Monday, 19 September 2011 10:29:17 UTC+1, David wrote:
>
> Hi Daniel
>
> Re: (2.)
>
> company.purchase_set.all returns nothing in my template.
>
What happens when you try it in the shell?
Are you sure that you have any purchases for that company?
> This is my sel
Hi Daniel
Re: (2.)
company.purchase_set.all returns nothing in my template.
This is my select_related line:
a = Company.objects.select_related().get(pk=pk)
Regarding your reply (1.) because there are no FK's in the company
table I had assumed that Django must be using reverse relatio
On Monday, 19 September 2011 10:06:06 UTC+1, David wrote:
>
> Hello
>
> Can/does select_related traverse models in other installed apps? and
> if not, can it be?
>
> I have the following
>
> app1
> class company
> no FKs
>
> class person
> FK to co
Hello
Can/does select_related traverse models in other installed apps? and
if not, can it be?
I have the following
app1
class company
no FKs
class person
FK to company
app2
class purchase
FK to person
I can access both company and person rendering like this in my
template
mpty, for some reason that I can't explain.
>
>
> a.b_set isn't a QuerySet; it's a RelatedManager. For most uses, it's
> almost the same; but not exactly. try reversing the select_related()
> and all() calls (all() returns a QuerySet):
>
> b_set = a.b_set.all().
7;t a QuerySet; it's a RelatedManager. For most uses, it's
almost the same; but not exactly. try reversing the select_related()
and all() calls (all() returns a QuerySet):
b_set = a.b_set.all().select_related()
--
Javier
--
You received this message because you are subscribed to the Goo
Hi all,
I'm seeing some funny behavior when using select_related to try to speed up
my code, and I'm wondering if I'm just misunderstanding something.
The basics of my code:
class A(models.Model):
# some stuff
class B(models.Model):
a = models.ForeignKey('A')
2_related (if
> needed).
> You can then call A.foo1_related() and get what you need.
That sounds good to me! I will definitely head that route.
The primary thing I like about select_related is that I can do this on
the template level (for example):
{% with object.file1.select
When I run:
>
> ...foo.select_related()
>
> I get all of the B entries related to A instance.
>
> I would like to write a method similar to select_related() (I need to
> customize the query), but I am not sure how to implement such a query.
>
> I have been hammering at th
entries related to A instance.
I would like to write a method similar to select_related() (I need to
customize the query), but I am not sure how to implement such a query.
I have been hammering at this all day, and I gave up on the idea of writing
my own select_related() method and I have most rec
Dear Martin,
Am 14.04.2011 15:26, schrieb Martin J. Laubach:
Sounds like a join with a table that doesn't have all the rows. Let me
guess: the tables have been filled by some other program and you are
just reading them from Django -- and you are missing a blank=True,
null=True on a ForeignKey in
Sounds like a join with a table that doesn't have all the rows. Let me
guess: the tables have been filled by some other program and you are just
reading them from Django -- and you are missing a blank=True, null=True on a
ForeignKey in your Django models somewhere.
Cheers,
mjl
--
Hi all,
using Django 1.3 with Python 2.6.5 on Ubuntu 10.04 and mod_wsgi, with
Oracle database, in addition to
http://code.djangoproject.com/ticket/15766, I seem to have come over
another problem with select_related():
The same queryset produces different results (number of returned
Dear Ian,
Am 04.04.2011 22:27, schrieb Ian:
Yes, this appears to be a bug. If you would, please create a ticket
for it in the Django Trac so that we don't forget about it.
Gladly:
http://code.djangoproject.com/ticket/15766
Best regards,
Carsten
--
Cafu - the open-source Game and Graphi
On Apr 4, 12:05 pm, Carsten Fuchs wrote:
> Is this a bug in Django?
> If not, is there a better solution to the problem than using
> isinstance() in every place where I have to compare DecimalField values?
> (I'm still quite new to Python, and might be overlooking something
> obvious...)
Yes, thi
Dear Django list,
using Django 1.3 with Python 2.6.5 on Ubuntu 10.04 and mod_wsgi, with
Oracle database, I've just experienced a case where the use of
select_related() changes the result type of a DecimalField in a related
object from decimal.Decimal to float (which in turn brea
I'm using python 2.4 and django 1.2.4 with MySQL 5.0 FWIW
I have the following models (code deleted to simplify)
class Message(models.Model):
facility= models.CharField(max_length=2, null=True, blank=True)
msgtype = models.CharField(max_length=3)
class Pv(models.Model):
mess
plays fine. I'm sure this isn't right now.
This worked on the 8th. I updated to the latest svn today and this
came up. Not sure what the deal is.
def select_related(self, *fields, **kwargs):
"""
Returns a new QuerySet instance that will select relat
On Sun, Jan 30, 2011 at 7:27 AM, Miguel Araujo wrote:
> I didn't know that, that's why it was happening. I didn't post my models, as
> I wasn't sure that would help.
Btw, it's documented behavior:
http://docs.djangoproject.com/en/1.2/ref/models/querysets/#select-related
--
Ramiro Morales
--
> Hi everyone,
>>
>> I have been working on reducing DB queries in my project with great
>> results. But I have realized that select_related in one of my models doesn't
>> preload all the ForeignKeys and OneToOneFields, it preloads 3 out of 5.
>> Actually the 3 p
On Saturday, January 22, 2011 1:38:22 PM UTC, maraujop wrote:
>
> Hi everyone,
>
> I have been working on reducing DB queries in my project with great
> results. But I have realized that select_related in one of my models doesn't
> preload all the ForeignKeys and OneToO
Hi,
Please anyone confirm if this is normal, so I can report it or not.
Thanks, regards
Miguel Araujo
@maraujop
2011/1/22 Miguel Araujo
> Hi everyone,
>
> I have been working on reducing DB queries in my project with great
> results. But I have realized that select_related
Hi everyone,
I have been working on reducing DB queries in my project with great results.
But I have realized that select_related in one of my models doesn't preload
all the ForeignKeys and OneToOneFields, it preloads 3 out of 5. Actually the
3 preloaded are ForeignKeys and the other
y I have a ModelForm that contains this owner field. When
I render that form for an instance of a task, the django method
models_to_dict() is called to get the initial values for the task.
For my owner field, it sets the initial value to the numeric id of the
user.
This seems to negate any utili
No.
select_related() will work on ForeignKey() relationships and OneToOneField()
relationships and reverse OneToOneField() relationships.
Example:
class Blog(models.Model):
title = models.CharField()
> class Entry(models.Model):
body = models.TextField()
b
Does select_related() work if used on a ManyToMany field?
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-user
Hey there,
Let's say that I have these models:
*from django.contrib.auth.models import User*
*
*
*class Publisher:*
*name = Char(x)*
*
*
*class Author:*
*publisher = FK(Publisher)*
*name = Char(x)*
*
*
*class Book:*
*user = FK(User)*
*author = FK(Author)*
*name = Char(x)*
an email address, this will
> produce an empty list. Is there any way to force select_related to do
> a LEFT JOIN so that even if email is null, the person is returned with
> email set to null.
You have set the email field (implicitly) as null=False, that is,
every person must have an asso
an email address, this will
> produce an empty list. Is there any way to force select_related to do
> a LEFT JOIN so that even if email is null, the person is returned with
> email set to null.
>
> Cheers,
> Thusjanthan.
It's not possible for a Person to exist without an Emai
When I do: Person.objects.select_related().all()
The query that is run is:
SELECT id,email FROM Person INNER JOIN Email ON (Person.id =
Email.id)
As you can see if a person did not have an email address, this will
produce an empty list. Is there any way to force select_related to do
a LEFT JOIN so that even if ema
Uhh, you are right... it does work!
I though I was writing a pseudo code (without testing that my pseudo
code indeed worked already)... Sometimes Django is intuitive to extent
it guesses what I wanted!
Though foreignkey documentation did not include information that I can
access the raw ID like "
On Jul 12, 11:29 am, Jari Pennanen wrote:
> Hi!
>
> Is it possible to access the foreignkey ID value of model? I do not
> want Django ORM to try to make query because it fails in this case. I
> have exact same problem
> ashttp://groups.google.com/group/django-users/browse_thread/thread/d24f...
>
Hi!
Is it possible to access the foreignkey ID value of model? I do not
want Django ORM to try to make query because it fails in this case. I
have exact same problem as
http://groups.google.com/group/django-users/browse_thread/thread/d24f2a502da3171c?pli=1
(though I'm not using admin, I have list
s if you set
> list_select_related = True, or if one of the list_display fields is a
> ForeignKey. (http://docs.djangoproject.com/en/dev/ref/contrib/admin/
> #django.contrib.admin.ModelAdmin.list_select_related)
>
> So you can reproduce this by calling select_related. But my question
fields is a
ForeignKey. (http://docs.djangoproject.com/en/dev/ref/contrib/admin/
#django.contrib.admin.ModelAdmin.list_select_related)
So you can reproduce this by calling select_related. But my question
is "How does this happen?". What are the lines of code that remove
the 5 rows w
I really appreciate your help Dan, but I don't think the answer to my question
is in the docs. I did my due diligence there before asking.
Regarding your suggestion, from the docs: "It's an error to use both a list of
fields and the depth parameter in the same select_related() c
y to specifically prevent it from following other
> relationships on the "person" model?
>
> The docs seem to be ambiguous on this point.
>
> Thanks,
> Michael
>
> On Thursday 10 June 2010 03:37:59 pm Dan Harris wrote:
>
>
>
> > According to the sel
According to the select_related() documentation at:
http://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.QuerySet.select_related
it looks like select related "follows foreign keys as far as
possible". In the documentation example it shows select_related
following
rsday 10 June 2010 03:37:59 pm Dan Harris wrote:
> According to the select_related() documentation at:
> http://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models
> .QuerySet.select_related
>
> it looks like select related "follows foreign keys as far as
If I use select_related() on a queryset and specify some attribute names, will
it follow those relationships as far as possible, or does that imply
"depth=1"?
Thanks,
Michael
signature.asc
Description: This is a digitally signed message part.
I am trying to use a raw sql query in a model manager method.
RawQuerySet lacks method _clone, is there a recommended way to return
a normal QuerySet for views to consume?
The models are included below. If there is a way to get the Django ORM
to make the M2M join via select_related and extra, I&#
On Apr 23, 12:03 am, Continuation wrote:
> Is there any way to do something similar to select_related() when
> following a foreign key relationship backward?
>
> For example,
> b = Blog.objects.get(id=1)
> e = b.entry_set.all()
>
> Any way to retrieve both b and e in one s
Is there any way to do something similar to select_related() when
following a foreign key relationship backward?
For example,
b = Blog.objects.get(id=1)
e = b.entry_set.all()
Any way to retrieve both b and e in one single DB query?
--
You received this message because you are subscribed to the
pm, Daishy wrote:
>
>
>
>
>
> > Hi together,
>
> > I'm trying to use select_related in a query, but it seems i'm doing
> > something wrong. I have googled, but not really found anything (Maybee
> > used the wrong keywords :/)
>
> > I&#x
On Apr 18, 5:32 pm, Daishy wrote:
> Hi together,
>
> I'm trying to use select_related in a query, but it seems i'm doing
> something wrong. I have googled, but not really found anything (Maybee
> used the wrong keywords :/)
>
> I've got a model that is related
Hi together,
I'm trying to use select_related in a query, but it seems i'm doing
something wrong. I have googled, but not really found anything (Maybee
used the wrong keywords :/)
I've got a model that is related to another model, roughly like that:
class A(models.Model):
a = m
e
> table for A does not exist. This same issue occurs if I try to do
> B.objects.filter(a__name='Fred'). Am I right in assuming that this
> usage just isn't possible, or is there something that I've missed (I
> was unable to find any mention of this situation in eith
ming that this
usage just isn't possible, or is there something that I've missed (I
was unable to find any mention of this situation in either the multi-
db documentation[1] or the select_related documentation[2])?
Theoretically the query should be possible as both databases are on
the same h
Hello,
Here is an extremely simple scenario:
class Base(models.Model):
f1 = models.CharField(max_length=64)
class A(Base):
f2 = models.CharField(max_length=64)
class B(models.Model):
f3 = models.CharField(max_length=64)
b = models.OneToOneField('A', null=False, related_name="b_o
ies?
>
> It seems like the relationship between gate and keywords is a reverse
> one - that is, the foreign key is from keyword to gate, not the other
> way round. select_related() doesn't work on reverse relationships.
> --
yes it is. But this generate no error and
key is from keyword to gate, not the other
way round. select_related() doesn't work on reverse relationships.
--
DR.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this g
I used query in form
a = X.objects.select_related('gate__keywords_set').filter(field=value)
and then tried to get elements from related
a[x].gate.keywords_set - there is a RelatedManager object which forces
me to call all() method to get elements. And problem is that this
causes additional queri
Thanks for the reply,
This is much more complex than I thought..
I will stay with the way of two queries, better than one query per
object..
Gleber
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group
1 - 100 of 275 matches
Mail list logo
