Code

Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#930 closed defect (duplicate)

[patch] Leaving out ¨ordering¨ in OneToOne relationship causes bad SQL statement

Reported by: EABinGA Owned by: russellm
Component: Metasystem Version:
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Using Trunk rev-1461:

Given the Model Foo:

from django.core import meta

# Create your models here.

class Bar(meta.Model):
    class META:
        admin = meta.Admin()
        
    bardata = meta.CharField(maxlength=200)
    
    def __repr__(self):
        return self.bardata
        
class Baz(meta.Model):
    class META:
        admin = meta.Admin()
        
    bazdata = meta.CharField(maxlength=200)
    bar = meta.OneToOneField(Bar)

    def __repr__(self):
        return self.bazdata

When you select ¨baz¨ from the main admin interface:

You are greeted by the following:

OperationalError at /admin/foo/bazs/
no such column: foo_bars.id
Request Method: 	GET
Request URL: 	http://127.0.0.1:8080/admin/foo/bazs/
Exception Type: 	OperationalError
Exception Value: 	no such column: foo_bars.id
Exception Location: 	/usr/lib/python2.4/site-packages/Django-0.90-py2.4.egg/django/core/db/backends/sqlite3.py in execute, line 71

The offending SQL statement seems to be:

SELECT "foo_bazs"."bazdata","foo_bazs"."bar_id" FROM "foo_bazs" ORDER BY "foo_bars"."id" DESC

Explicitly including an ¨ordering¨ in the ¨baz¨ class fixes this problem, but it should work properly without one.

ALSO:
Upon creation of a ¨baz¨, the admin interface of ¨baz¨ shows a label of ¨ID¨ folowed by a dropdown list containing bars followed by what seems to be the PK of said bar. What is the purpose of that number? Is it supposed to be there.

Additionally, once a baz is saved, the dropdown list suggests, that corresponding bar for this baz can be changed, but saving the baz with a different bar does not seem to have any effect.

Attachments (2)

930_patch.diff (1.1 KB) - added by django@… 9 years ago.
ordering_foreignkey.diff (699 bytes) - added by dodysw@… 9 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 9 years ago by django@…

I'm having the same problem, using a OneToOne to auth.User. Adding the order by table name to the sql statement removes the error.

Changed 9 years ago by django@…

comment:2 Changed 9 years ago by anonymous

  • Summary changed from Leaving out ¨ordering¨ in OneToOne relationship causes bad SQL statement to [patch] Leaving out ¨ordering¨ in OneToOne relationship causes bad SQL statement

Changed 9 years ago by dodysw@…

comment:3 Changed 8 years ago by anonymous

The patch (930_patch.diff) has a problem that creates other SQL errors at times.

From IRC:

<bruce> Anyone around that can give advice on how to fix a problem in core/meta/init.py in

function_get_sql_clause?

<bruce> It generates invalid SQL if you have an order_by and select_related = True due to how it

handles not having duplicated table names in the list of tables.

<bruce> The reason for that is that it does the order_by, adds those tables to the list .. but doesn't

pass them in the list as the final parameter to _fill_table_cache when handling the
select_related, so _fill_table_cache thinks that they're not in the list and adds them again.

<bruce> I think that the way around that is to do a tables_seen = [] before going over the order_by,

add the order_by tables to that, add opts.db_table and then pass that list rather than
[opts.db_table] to _fill_table_cache

I did that fix and it worked, but then some things were getting returned multiple times I think. I ended up just backing out the patch in 930_patch.diff.

comment:4 Changed 8 years ago by russellm

  • Owner changed from adrian to russellm

The _get_sql_clause stuff has been reorganised a bit in magic_removal - I'll check to make sure that this problem doesn't still exist.

comment:5 Changed 8 years ago by Brian Ray <bray@…>

I do not know about the magic_removal branch but I am experiencing the same problem on svn TIP (2075).

I am trying to extend auth.Users with a OneToOneField.

class nwmuser(meta.Model):

user = meta.OneToOneField(auth.User)
first = meta.DateTimeField("First Appearance")
class META:

admin = meta.Admin()

ERROR: missing FROM-clause entry for table "auth_users"
SELECT

"abc_nwmusers"."user_id",
"abc_nwmusers"."first"
FROM "abc_nwmusers"

ORDER BY "auth_users"."username" DESC;

If I punch the same query into psql I get the same thing.

comment:6 Changed 8 years ago by anonymous

  • priority changed from normal to high

just apply this patch for now.

comment:7 Changed 8 years ago by WorldMaker

This issue affects the magic_removal branch as well. (I'm coding against revision 2123 tonight.)

comment:8 Changed 8 years ago by bruno@…

See also #1245 (same problem)

comment:9 Changed 8 years ago by Jorge Gajon <gajon@…>

A patch was submitted in ticket #1245. Instead of including the related table with lookup_paramsselect_related? = True, that patch constructs the lookup_order_field differently when the ordering field is a OneToOne field.

It is not necessary to specify an ordering attribute.

comment:10 Changed 8 years ago by jkocherhans

  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #1245. The patch here forces an implicit select_related which is well... not explicit enough ;) It can and should be avoided.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.