Re: Overriding the JOIN type in contrib.admin's search forms?
Followup: This bug is fully fixed on the newforms_admin branch. Thanks for the help! --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Overriding the JOIN type in contrib.admin's search forms?
On Jun 23, 11:30 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote: > It's a leap from no response to nobody cares. Yes, sorry for that, I didn't mean to be rude. > One thing, though, which may have made a lot of people pass over it is that > you are reporting a problem with they way queries are constructed on 0.96. > Since 0.96 was released the guts of the query-construction logic inside > Django has been completely rewritten. (You've probably seen this referenced > on this list -- the 'queryset-refactor' branch that was merged back into the > SVN trunk a couple of months ago.) Ah, I see. I wasn't around then, I'm brand new to Django. I don't think it's unusual to report bugs against the latest stable release though. > Can you try your scenario on current trunk? You'll probably get more > interest in a problem reported against trunk than 0.96. Certainly any fix > made for the problem will only become available in a trunk checkout and then > in 1.0; the only fixes made to 0.96 are security related. Okay, after a bit of upgrade pain I got my app running against trunk. The join type has been changed, so I get all results now; but it's not using DISTINCT so I still get the unexpected duplicates. Thanks for the help, I'll go update the bug report with the trunk behavior. --~--~-~--~~~---~--~~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Overriding the JOIN type in contrib.admin's search forms?
On Mon, Jun 23, 2008 at 4:01 PM, Paul Winkler <[EMAIL PROTECTED]> wrote:
> Nobody cares?
> To me this seems like a significant bug in contrib.admin ... okay I'm
> filing it as such:
> http://code.djangoproject.com/ticket/7528
>
It's a leap from no response to nobody cares. Remember people on this list
are doing so primarily in their spare time. So your report could just have
come at a bad time when people didn't have the extra time to devote to it.
One thing, though, which may have made a lot of people pass over it is that
you are reporting a problem with they way queries are constructed on 0.96.
Since 0.96 was released the guts of the query-construction logic inside
Django has been completely rewritten. (You've probably seen this referenced
on this list -- the 'queryset-refactor' branch that was merged back into the
SVN trunk a couple of months ago.) It's quite possible that the problem you
are reporting was fixed as a result of that major change.
Can you try your scenario on current trunk? You'll probably get more
interest in a problem reported against trunk than 0.96. Certainly any fix
made for the problem will only become available in a trunk checkout and then
in 1.0; the only fixes made to 0.96 are security related.
Karen
>
> On Jun 17, 2:08 pm, Paul Winkler <[EMAIL PROTECTED]> wrote:
> > Bear with me, I'm a Django novice, still reading docs...
> >
> > I'm trying to build my first app using django admin (release 0.96),
> > because it's a good match to the requirements (a quick and simple CRUD
> > application).
> >
> > I found a thread from last yearhttp://
> groups.google.com/group/django-users/browse_thread/thread/b086...
> > where the last post describes the same problem I'm having, but there
> > were no further replies.
> >
> > All was coming along nicely until I started using 'the lookup API
> > "follow" notation' to get a foreign key into my search_fields, like
> > this:
> >
> > class FilmClip(models.Model):
> > ...
> > class Admin:
> > ...
> > search_fields = ('clip_id', 'label', 'description',
> > 'filmcliplog__description' # This is the
> > line that causes problems
> > )
> >
> > class FilmClipLog(models.Model):
> > clip = models.ForeignKey(FilmClip,
> > edit_inline=models.TABULAR,
> > num_in_admin=3)
> > ...
> >
> > There are two problems with the resulting behavior:
> > 1) Any matching FilmClip thas has at least one FilmClipLog will show
> > up in the results twice.
> > 2) Any matching FilmClip that has no FilmClipLogs will not show up at
> > all.
> >
> > From the mysql query log, I've found that the query looks like:
> >
> > SELECT ... FROM `filmy_filmclip` INNER JOIN `filmy_filmcliplog` ...
> >
> > But what I want is this:
> >
> > SELECT DISTINCT ... FROM `filmy_filmclip` LEFT OUTER JOIN
> > `filmy_filmcliplog` ...
> >
> > So, my questions:
> >
> > 1) Is this a Django bug? When would the existing behavior be
> > desirable?
> >
> > 2) Is there a way to specify the type of join in the search query?
> >
> > 3) Is there a way to add DISTINCT to the search query?
> >
> > 4) If no, what's the quickest way to get the behavior I want?
> >
> > Thanks,
> >
> > - PW
> >
>
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Overriding the JOIN type in contrib.admin's search forms?
Nobody cares?
To me this seems like a significant bug in contrib.admin ... okay I'm
filing it as such:
http://code.djangoproject.com/ticket/7528
- PW
On Jun 17, 2:08 pm, Paul Winkler <[EMAIL PROTECTED]> wrote:
> Bear with me, I'm a Django novice, still reading docs...
>
> I'm trying to build my first app using django admin (release 0.96),
> because it's a good match to the requirements (a quick and simple CRUD
> application).
>
> I found a thread from last
> yearhttp://groups.google.com/group/django-users/browse_thread/thread/b086...
> where the last post describes the same problem I'm having, but there
> were no further replies.
>
> All was coming along nicely until I started using 'the lookup API
> “follow” notation' to get a foreign key into my search_fields, like
> this:
>
> class FilmClip(models.Model):
> ...
> class Admin:
> ...
> search_fields = ('clip_id', 'label', 'description',
> 'filmcliplog__description' # This is the
> line that causes problems
> )
>
> class FilmClipLog(models.Model):
> clip = models.ForeignKey(FilmClip,
> edit_inline=models.TABULAR,
> num_in_admin=3)
> ...
>
> There are two problems with the resulting behavior:
> 1) Any matching FilmClip thas has at least one FilmClipLog will show
> up in the results twice.
> 2) Any matching FilmClip that has no FilmClipLogs will not show up at
> all.
>
> From the mysql query log, I've found that the query looks like:
>
> SELECT ... FROM `filmy_filmclip` INNER JOIN `filmy_filmcliplog` ...
>
> But what I want is this:
>
> SELECT DISTINCT ... FROM `filmy_filmclip` LEFT OUTER JOIN
> `filmy_filmcliplog` ...
>
> So, my questions:
>
> 1) Is this a Django bug? When would the existing behavior be
> desirable?
>
> 2) Is there a way to specify the type of join in the search query?
>
> 3) Is there a way to add DISTINCT to the search query?
>
> 4) If no, what's the quickest way to get the behavior I want?
>
> Thanks,
>
> - PW
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Overriding the JOIN type in contrib.admin's search forms?
Bear with me, I'm a Django novice, still reading docs...
I'm trying to build my first app using django admin (release 0.96),
because it's a good match to the requirements (a quick and simple CRUD
application).
I found a thread from last year
http://groups.google.com/group/django-users/browse_thread/thread/b0866749612aaeae/135d13ce40c33aa7?lnk=gst&q=admin+search_fields+join#135d13ce40c33aa7
where the last post describes the same problem I'm having, but there
were no further replies.
All was coming along nicely until I started using 'the lookup API
“follow” notation' to get a foreign key into my search_fields, like
this:
class FilmClip(models.Model):
...
class Admin:
...
search_fields = ('clip_id', 'label', 'description',
'filmcliplog__description' # This is the
line that causes problems
)
class FilmClipLog(models.Model):
clip = models.ForeignKey(FilmClip,
edit_inline=models.TABULAR,
num_in_admin=3)
...
There are two problems with the resulting behavior:
1) Any matching FilmClip thas has at least one FilmClipLog will show
up in the results twice.
2) Any matching FilmClip that has no FilmClipLogs will not show up at
all.
From the mysql query log, I've found that the query looks like:
SELECT ... FROM `filmy_filmclip` INNER JOIN `filmy_filmcliplog` ...
But what I want is this:
SELECT DISTINCT ... FROM `filmy_filmclip` LEFT OUTER JOIN
`filmy_filmcliplog` ...
So, my questions:
1) Is this a Django bug? When would the existing behavior be
desirable?
2) Is there a way to specify the type of join in the search query?
3) Is there a way to add DISTINCT to the search query?
4) If no, what's the quickest way to get the behavior I want?
Thanks,
- PW
--~--~-~--~~~---~--~~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
