On Fri, Jan 2, 2009 at 9:46 PM, Friendless <friendless.farr...@gmail.com>wrote:
>
> I still can't log in. Sometimes I get a dialogue box, sometimes a
> form, but it just never works. My username is Friendless.
Did you try just filling in some settings at the page I pointed to in the
earlier mail? That method doesn't require login. Sorry, I can't help with
the login not working, I don't have (nor want) any ability to do anything
with trac logins. You are the first person I recall ever reporting a
problem with one, though.
Anyway, as I
> have your permission to post my bug here, I'll do so. I have a legacy
> MySQL database to which I'm adding access using Django. I wrote the
> create scripts for this db by hand while I was learning MySQL so
> they're "quirky". I ran inspectdb and it failed like this:
>
> Traceback (most recent call last):
> [snipped]
File "/usr/lib/python2.5/site-packages/django/db/backends/mysql/
> introspection.py", line 80, in get_relations
> other_field_index = self._name_to_index(cursor, other_table)
> [other_field]
> KeyError: u'BGGID'
>
> i.e. it can't find the column that I have a foreign key constraint on.
> The tables in question are:
>
> CREATE TABLE `expansions` (
> `basegame` int(10) unsigned NOT NULL,
> `expansion` int(10) unsigned NOT NULL,
> KEY `expansions_basegame` (`basegame`),
> KEY `expansions_expansion` (`expansion`),
> CONSTRAINT `expansions_basegame` FOREIGN KEY (`basegame`) REFERENCES
> `games` (`BGGID`),
> CONSTRAINT `expansions_expansion` FOREIGN KEY (`expansion`)
> REFERENCES `games` (`BGGID`)
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8
>
> CREATE TABLE `games` (
> `bggid` int(10) unsigned NOT NULL,
> `name` varchar(256) NOT NULL default '',
> `average` float default '0',
> `rank` int(11) default '-1',
> `yearPublished` int(11) default '0',
> `minPlayers` int(10) unsigned default '0',
> `maxPlayers` int(10) unsigned default '0',
> `playTime` int(10) unsigned default '0',
> `usersRated` int(10) unsigned default '0',
> `usersTrading` int(10) unsigned default '0',
> `usersWanting` int(10) unsigned default '0',
> `usersWishing` int(10) unsigned default '0',
> `averageWeight` float default '0',
> `bayesAverage` float default '0',
> `stdDev` float default '0',
> `median` float default '0',
> `numComments` int(10) unsigned default '0',
> `expansion` int(10) unsigned NOT NULL default '0',
> `thumbnail` varchar(256) default '',
> `usersOwned` int(10) unsigned default '0',
> PRIMARY KEY (`bggid`)
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8
>
> Note that in the first table the column name is BGGID and in the
> second it's bggid. I always presumed this worked as MySQL doesn't
> complain, and I hope it would if I defined a constraint that made no
> sense.
(Well, yes, one would hope that...whether you can really count on it, I
don't know.) You certainly picked an odd one to trip over in your first 30
minutes of using Django. What version of MySQL are you using? I cannot
recreate this behavior with:
Server version: 5.0.45-Debian_1ubuntu3.4-log Debian etch distribution
If I cut and paste your create table statements into a mysql command session
(with one specifying all uppercase BGGID and one all lowercase), a
subsequent inspectdb runs fine. Inspecing the output of the command Django
uses to query the DB:
mysql> select column_name,
-> referenced_table_name,
-> referenced_column_name
-> from information_schema.key_column_usage
-> where
-> table_name = 'expansions' and
-> table_schema = DATABASE() and
-> referenced_table_name is not null and
-> referenced_column_name is not null;
+-------------+-----------------------+------------------------+
| column_name | referenced_table_name | referenced_column_name |
+-------------+-----------------------+------------------------+
| basegame | games | bggid |
| expansion | games | bggid |
+-------------+-----------------------+------------------------+
2 rows in set (0.00 sec)
shows mysql is returning all-lowercase even though the create table I used
specified it as all-uppercase. So I am wondering if the behavior you see is
a bug they have fixed, perhaps?
> Anyway, I hacked the code in introspection.py. I changed line
> 80 to this:
>
> other_field_index = self._name_to_index(cursor, other_table)
> [other_field.lower()]
>
> i.e. I just added the .lower(), and it works for me, and then
> inspectdb worked fine.
That fix seems a bit fragile. I wonder what would happen if you specified
all-uppercase BGGD in the games table and all-lowercase in the expansions
table what behavior you would see and if instead of .lower() here you would
need an .upper() to make things work?
> Anyway, the problem is that inspectdb fails due
> to case quirks, and with a completely unhelpful error message. It
> would be so much nicer if it either figured out for itself (which it
> should do if the case difference is a valid thing to do), or else give
> a better error message.
Agreed. Apparently column names are not case-sensitive for MySQL and if
MySQL may return them with different cases in different places than it would
be nice if inspecdb would not fall over and die with a cryptic error
message. I'm a little afraid, though, that the fix you came up with is
specific to how you had your tables specified and won't necessarily cover
other cases of the sameish sort of oddball situation. And if returning the
mismatched cases is something MySQL has already fixed on their side, I'm not
sure how much trouble Django should go to to accomodate this oddity....
Karen
--~--~---------~--~----~------------~-------~--~----~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
