SyncDB failure
James PIC
Description:
margaux mmm # ./manage.py syncdb
Creating table auth_permission
Creating table auth_group
Creating table auth_user
Creating table auth_message
Creating table django_content_type
Creating table django_session
Creating table django_site
Creating table django_admin_log
Creating table immo_zipcode
Creating table immo_zone
Creating table immo_configurationdeterrain
Creating table immo_formedeterrain
Creating table immo_terraintype
Creating table immo_secteur
Creating table immo_ville
Creating table immo_quartier
Creating table immo_departement
Creating table immo_pubpresse
Creating table immo_pubinternet
Creating table immo_categoriedelot
Creating table immo_categoriedeterrain
Creating table immo_categoriedehabitable
Creating table immo_categoriedelcp
Creating table immo_souscategoriedehabitable
Creating table immo_souscategoriedelcp
Creating table immo_genredebien
Creating table immo_loidefiscalisation
Creating table immo_equipementprivatif
Creating table immo_equipementcollectif
Creating table immo_annexe
Creating table immo_typedemandat
Creating table immo_typedebail
Creating table immo_activite
Creating table immo_activitepourlcp
Creating table immo_statutdebien
Creating table immo_typedecode
Creating table immo_code
Creating table immo_typedenvironnement
Creating table immo_environnement
Creating table immo_typedemeuble
Creating table immo_meuble
Creating table immo_typedepiece
Creating table immo_piece
Creating table immo_typedeinformationcomplementaire
Creating table immo_informationcomplementaire
Creating table immo_typedepiecelcp
Creating table immo_piecelcp
Creating table immo_typedeprestation
Creating table immo_mandat
Creating table immo_lotaddresse
Creating table immo_textes
Creating table immo_categoriededocument
Creating table immo_document
Creating table immo_imagepublique
Creating table immo_bien
Creating table immo_pourvente
Creating table immo_pourlocation
Creating table immo_terrain
Creating table immo_descriptifdeimmeuble
Creating table immo_lot
Creating table immo_lcp
Creating table immo_typetransactionlcp
Creating table immo_userprofile
Creating table immo_typedeinformationcomplementairecontact
Creating table immo_informationcomplementairecontact
Creating table immo_typedeclient
Creating table immo_civilite
Creating table immo_contactclassification
Creating table immo_location
Creating table immo_lotissement
Creating table immo_residence
Creating table immo_descriptifderesidence
Creating table immo_prestationderesidence
Creating table registration_registrationprofile
Creating table django_project_version
Creating table django_evolution
You just installed Django's auth system, which means you don't have
any superusers defined.
Would you like to create one now? (yes/no): no
Installing baseline version
Traceback (most recent call last):
File "./manage.py", line 11, in <module>
execute_manager(settings)
File "/home/mmm/sites/mmm/__init__.py", line 340, in execute_manager
File "/home/mmm/sites/mmm/__init__.py", line 295, in execute
File "/home/mmm/django/core/management/base.py", line 195, in run_from_argv
File "/home/mmm/django/core/management/base.py", line 222, in execute
File "/home/mmm/django/core/management/base.py", line 351, in handle
File "/home/mmm/lib/django/core/management/commands/syncdb.py", line
98, in handle_noargs
emit_post_sync_signal(created_models, verbosity, interactive)
File "/home/mmm/lib/django/core/management/sql.py", line 205, in
emit_post_sync_signal
interactive=interactive)
File "/home/mmm/django/dispatch/dispatcher.py", line 148, in send
File "/home/mmm/lib/django/contrib/auth/management/__init__.py",
line 28, in create_permissions
defaults={'name': name, 'content_type': ctype})
File "/home/mmm/django/db/models/manager.py", line 96, in get_or_create
File "/home/mmm/django/db/models/query.py", line 339, in get_or_create
File "/home/mmm/django/db/models/base.py", line 328, in save
File "/home/mmm/django/db/models/base.py", line 400, in save_base
File "/home/mmm/django/db/models/manager.py", line 138, in _insert
File "/home/mmm/django/db/models/query.py", line 894, in insert_query
File "/home/mmm/django/db/models/sql/subqueries.py", line 309, in execute_sql
File "/home/mmm/django/db/models/sql/query.py", line 1756, in execute_sql
File "/home/mmm/django/db/backends/util.py", line 19, in execute
psycopg2.ProgrammingError: value too long for type character varying(50)
Apparently, this patch fixed it:
Index: ../../lib/django/contrib/auth/models.py
===================================================================
--- ../../lib/django/contrib/auth/models.py (revision 9637)
+++ ../../lib/django/contrib/auth/models.py (working copy)
@@ -60,9 +60,9 @@
Three basic permissions -- add, change and delete -- are
automatically created for each Django model.
"""
- name = models.CharField(_('name'), max_length=50)
+ name = models.CharField(_('name'), max_length=100)
content_type = models.ForeignKey(ContentType)
- codename = models.CharField(_('codename'), max_length=100)
+ codename = models.CharField(_('codename'), max_length=150)
class Meta:
verbose_name = _('permission')
Is it worth reporting the bug?
Regards, James.
Russell Keith-Magee
>
> Is it worth reporting the bug?
It isn't entirely clear what "the bug" is. All that you have given us
is an error message, and a solution that you have worked out. What you
haven't given us is enough detail to reproduce the problem for
ourself. We don't know what your project looks like, what is contained
in your apps, if there is any strange synchronization logic being
triggered - all we have is an error message. A cut down project
definition that can't be synchronized would be the minimum requirement
before you reported this bug in a ticket.
However, at a guess, I'm going to say that the problem has been caused
by your choice of model names. You appear to have named one of your
models something like TypedEInformationComplementaireContact. This is
a pretty long class name, and it is overflowing a column somewhere
that is using the class name as a starting point.
Your proposed fix (increasing the size of the columns) is really just
deferring the problem. No matter what maximum size we pick, someone
will choose a model name that will overflow it. I would have thought a
50 character limit was plenty, but obviously I was wrong. Your
solution also suffers from the problem of backwards compatibility -
there is a lot of existing code out there that relies on the existing
size definition.
A better solution would be to come up with a name munging scheme that
guaranteed to give unique permission names that will always fit into
the available space. 50 characters is plenty to establish a unique
name; we already perform a similar munging with the names for database
constraints.
Of course, the simplest solution is for you to pick shorter class
names, and for us to document the limitation. This solution has the
additional benefit of enforcing good programming practice. Having
descriptive class names is good, but I for one wouldn't derive much
joy from using an API that had class names that spanned 50% of the
width of a 80 character terminal :-)
Yours,
Russ Magee %-)
James PIC
>
> On Wed, Dec 17, 2008 at 9:30 PM, James PIC <jame...@gmail.com> wrote:
> >
> > Is it worth reporting the bug?
>
> by your choice of model names. You appear to have named one of your
> models something like TypedEInformationComplementaireContact. This is
> a pretty long class name, and it is overflowing a column somewhere
> that is using the class name as a starting point.
> Your proposed fix (increasing the size of the columns) is really just
> deferring the problem.
(I did not actually propose it, but used it to describe the problem).
> No matter what maximum size we pick, someone
> will choose a model name that will overflow it. I would have thought a
> 50 character limit was plenty, but obviously I was wrong. Your
> solution also suffers from the problem of backwards compatibility -
> there is a lot of existing code out there that relies on the existing
> size definition.
>
> A better solution would be to come up with a name munging scheme that
> guaranteed to give unique permission names that will always fit into
> the available space. 50 characters is plenty to establish a unique
> name; we already perform a similar munging with the names for database
> constraints.
That would be much smarter indeed!
> Of course, the simplest solution is for you to pick shorter class
> names, and for us to document the limitation.
I can change "Information" to "Info", but you have the point that it doesn't
fix the problem ... I just wanted to point it out.
> This solution has the
> additional benefit of enforcing good programming practice. Having
> descriptive class names is good, but I for one wouldn't derive much
> joy from using an API that had class names that spanned 50% of the
> width of a 80 character terminal :-)
Just for kidding:
class Lot(Mandat, Bien, PourLocation, PourVente, LotAddresse,
AvecEquipementsAnnexes, Textes, Immeuble):
It was that, or models with thousands of similar fields, high WTF/hour :)
Regards, James.
felix
That would be much smarter indeed!
> A better solution would be to come up with a name munging scheme that
> guaranteed to give unique permission names that will always fit into
> the available space. 50 characters is plenty to establish a unique
> name; we already perform a similar munging with the names for database
> constraints.
here, btw. is a bug I found, confirmed and submitted regarding that munging:
http://code.djangoproject.com/ticket/9253
the hash munging may vary depending on the OS you are on, and in my case on the deployment server it overflowed MySQL's allowable constraint identifier size.
just FYI
munging the constraint name is fine IMO, but I the the foreign keys to be readable.
the easiest thing to do is ....
> Of course, the simplest solution is for you to pick shorter class
> names, and for us to document the limitation.
Just for kidding:
class Lot(Mandat, Bien, PourLocation, PourVente, LotAddresse,
AvecEquipementsAnnexes, Textes, Immeuble):
It was that, or models with thousands of similar fields, high WTF/hour :)
just be thankful you aren't coding in german :)
felix
James PIC
>> class Lot(Mandat, Bien, PourLocation, PourVente, LotAddresse,
>> AvecEquipementsAnnexes, Textes, Immeuble):
>> It was that, or models with thousands of similar fields, high WTF/hour :)
>
> just be thankful you aren't coding in german :)
It's very business-specific, i ignore 90% of the terms in english.
Also, the program is country-legislation specific.
But as you can see, not using acronyms is part of the coding standart.
James PIC
Apparently, this was not triggered by class names, but by verbose_name length:
INSERT INTO "auth_permission" ("name", "content_type_id", "codename")
VALUES (%s, %s, %s) (u"Can change cat\xe9gorie d'immobilier
d'entreprise (LCP)", 44, u'change_categoriedelcp')
Traceback (most recent call last):
File "./manage.py", line 11, in <module>
execute_manager(settings)
File "//usr/lib/python2.5/site-packages/django/core/management/__init__.py",
line 340, in execute_manager
utility.execute()
File "//usr/lib/python2.5/site-packages/django/core/management/__init__.py",
line 295, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "//usr/lib/python2.5/site-packages/django/core/management/base.py",
line 192, in run_from_argv
self.execute(*args, **options.__dict__)
File "//usr/lib/python2.5/site-packages/django/core/management/base.py",
line 219, in execute
output = self.handle(*args, **options)
File "//usr/lib/python2.5/site-packages/django/core/management/base.py",
line 348, in handle
return self.handle_noargs(**options)
File "//usr/lib/python2.5/site-packages/django/core/management/commands/syncdb.py",
line 101, in handle_noargs
emit_post_sync_signal(created_models, verbosity, interactive)
File "//usr/lib/python2.5/site-packages/django/core/management/sql.py",
line 205, in emit_post_sync_signal
interactive=interactive)
File "//usr/lib/python2.5/site-packages/django/dispatch/dispatcher.py",
line 148, in send
response = receiver(signal=self, sender=sender, **named)
File "//usr/lib/python2.5/site-packages/django/contrib/auth/management/__init__.py",
line 28, in create_permissions
defaults={'name': name, 'content_type': ctype})
File "//usr/lib/python2.5/site-packages/django/db/models/manager.py",
line 96, in get_or_create
return self.get_query_set().get_or_create(**kwargs)
File "//usr/lib/python2.5/site-packages/django/db/models/query.py",
line 339, in get_or_create
obj.save(force_insert=True)
File "//usr/lib/python2.5/site-packages/django/db/models/base.py",
line 311, in save
self.save_base(force_insert=force_insert, force_update=force_update)
File "//usr/lib/python2.5/site-packages/django/db/models/base.py",
line 383, in save_base
result = manager._insert(values, return_id=update_pk)
File "//usr/lib/python2.5/site-packages/django/db/models/manager.py",
line 138, in _insert
return insert_query(self.model, values, **kwargs)
File "//usr/lib/python2.5/site-packages/django/db/models/query.py",
line 894, in insert_query
return query.execute_sql(return_id)
File "//usr/lib/python2.5/site-packages/django/db/models/sql/subqueries.py",
line 309, in execute_sql
cursor = super(InsertQuery, self).execute_sql(None)
File "/usr/lib/python2.5/site-packages/django/db/models/sql/query.py",
line 1734, in execute_sql
cursor.execute(sql, params)
File "/usr/lib/python2.5/site-packages/django/db/backends/util.py",
line 20, in execute
return self.cursor.execute(sql, params) # calls print sql, params
as you can see
psycopg2.DataError: value too long for type character varying(50)
This should be documented and/or an Exception should be thrown.
Should i file a bug report?
Regards, James.
Karen Tracey
Hi,
Apparently, this was not triggered by class names, but by verbose_name length:
INSERT INTO "auth_permission" ("name", "content_type_id", "codename")
VALUES (%s, %s, %s) (u"Can change cat\xe9gorie d'immobilier
d'entreprise (LCP)", 44, u'change_categoriedelcp')
Traceback (most recent call last):
[snip]
File "/usr/lib/python2.5/site-packages/django/db/backends/util.py",line 20, in execute
return self.cursor.execute(sql, params) # calls print sql, params
as you can see
psycopg2.DataError: value too long for type character varying(50)
This should be documented and/or an Exception should be thrown.
Should i file a bug report?
I believe this is already covered by:
http://code.djangoproject.com/ticket/8548
Though the original description references MySQL, not PostgreSQL, the fix is to catch it in validation,so should be database-independent.
Karen