syncdb fails on my deployment server (mysql 5.0.67 on ubuntu) with :
File "./manage.py", line 11, in <module>
execute_manager(settings)
...
_mysql_exceptions.OperationalError: (1059, "Identifier name
'releasesnewsletter_id_refs_abstractmailing_ptr_id_62770683bbc11c0b'
is too long")
the same codebase succeeds on my development server (mysql 5.0.51a on
OS X)
its a contraint being added.
ubuntu:
ALTER TABLE `website_releasesnewsletter_additional_recipients` ADD
CONSTRAINT
releasesnewsletter_id_refs_abstractmailing_ptr_id_14a73856b276acd4
FOREIGN KEY (`releasesnewsletter_id`) REFERENCES
`website_releasesnewsletter` (`abstractmailing_ptr_id`);
mac:
ALTER TABLE `website_artistnewsletter_additional_recipients` ADD
CONSTRAINT artistnewsletter_id_refs_abstractmailing_ptr_id_4326e0be
FOREIGN KEY (`artistnewsletter_id`) REFERENCES
`website_artistnewsletter` (`abstractmailing_ptr_id`);
the ticket I guess is here:
http://code.djangoproject.com/ticket/1820
so the constraint generates a hash now, and the mac happened to get a
shorter hash.
egregiously long table name + hash = TILT !
Besides renaming the class with a shorter name, I could just use a
shorter db_table name
BUT in all cases in django it builds the related fields using the
class name to lower, not the db_table name.
that could/should be changed I think. oh that would be really
backwards incompatible, wouldn't it.
even though AbstractMailing uses a db_table of AbsMail
CREATE TABLE `AbsMail` (
`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
`subject` varchar(100) NOT NULL,
`from_email` varchar(75) NOT NULL,
`status` varchar(32) NOT NULL,
`created_on` datetime NOT NULL,
`created_by_id` integer NOT NULL,
`sent_on` datetime NULL,
`content_type_id` integer NULL
)
the subclasses still use the class name:
CREATE TABLE `mailings_contactmailing` (
`abstractmailing_ptr_id` integer NOT NULL PRIMARY KEY,
`body` longtext NOT NULL
);
ALTER TABLE `mailings_contactmailing` ADD CONSTRAINT
abstractmailing_ptr_id_refs_id_5468a0a0 FOREIGN KEY
(`abstractmailing_ptr_id`) REFERENCES `AbsMail` (`id`);
the case of related fields its quite easy to offer
related_field="%s(db_table)_rel"
just offer it both the class and the db_table :
if not cls._meta.abstract and self.rel.related_name:
self.rel.related_name = self.rel.related_name % {'class':
cls.__name__.lower(),'db_table':cls._meta.db_table}
inheritance could be done the same way
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
