RE: Displaying the fields of two tables on the same admin page

[Giovannetti, Mark]

 
> 
> I am entering them on the same page otherwise I will have to note down
> the ids of people and publications table and then go to bridge table
> and insert the ids there. So the reason I want to enter in the same
> page is I will insert the ids into bridge table whenever I click save.
> I am not allowed to change the db design by the way and it sucks :)
> 

Does this not work the way you expect?

class People(models.Model):

 other fields

publications = models.ManyToManyField('Publication',
through='PeoplePublication',
)


class Publication(models.Model):

 other fields


class PeoplePublication(models.Model):

people = models.ForeignKey('People',...)
publication = models.ForeignKey('Publication',...)


in admin.py:

class PublicationInline(admin.TabularInline):
model = PeoplePublication
extra = 1

class PeopleAdmin(admin.ModelAdmin):
inlines = [PublicationInline]


admin.site.register(People, PeopleAdmin)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Content types and interaction with DeferredAttribute models

[Giovannetti, Mark]

FYI:

Trying to run unittests.

Using the .only() method on a queryset causes the content types
machinery to find and attempt to use a model with Deferred attributes.

This function (with print and verbosity added):

def update_contenttypes(app, created_models, verbosity=2, **kwargs):
"""
Creates content types for models in the given app, removing any
model
entries that no longer have a matching model class.
"""
verbosity=2
ContentType.objects.clear_cache()
content_types =
list(ContentType.objects.filter(app_label=app.__name__.split('.')[-2]))
app_models = get_models(app)
#print "app, app_models", app, app_models
if not app_models:
return
for klass in app_models:
opts = klass._meta
#print "klass, opts", klass, opts, opts.__dict__
try:
ct = ContentType.objects.get(app_label=opts.app_label,
 model=opts.object_name.lower())
content_types.remove(ct)
except ContentType.DoesNotExist:
ct = ContentType(name=smart_unicode(opts.verbose_name_raw),
app_label=opts.app_label,
model=opts.object_name.lower())
print ct.name, len(ct.name), ct.app_label, ct.model
ct.save()
if verbosity >= 2:
print "Adding content type '%s | %s'" % (ct.app_label,
ct.model)

[...]

while running unittests, gives this output and error.

Adding content type 'contact | webaddress'
postal address 14 contact postaladdress
Adding content type 'contact | postaladdress'
postal address boundary 23 contact postaladdressboundary
Adding content type 'contact | postaladdressboundary'
contact mechanism link 22 contact contactmechanismlink
Adding content type 'contact | contactmechanismlink'

===
Output of:
print ct.name, len(ct.name), ct.app_label, ct.model gives:

contact mechanism type_
deferred_creation_date_time_description_display_is_default_privilege_tok
en_record_deleted_record_enabled 128 contact 
contactmechanismtype_deferred_creation_date_time_description_display_is_
default_privilege_token_record_deleted_record_enabled
===
Traceback (most recent call last):
  File
"C:\1mvgdocs\neodfos_workspace\neodfos\trunk\src\tools\tests\run_tests.p
y", line 245, in 
test_name =
connection.creation.create_test_db(verbosity=db_verbosity,
autoclobber=autoclobber)
  File "C:\Python26\lib\site-packages\django\db\backends\creation.py",
line 336, in create_test_db
call_command('syncdb', verbosity=verbosity, interactive=False)
  File
"C:\Python26\lib\site-packages\django\core\management\__init__.py", line
166, in call_command
return klass.execute(*args, **defaults)
  File "C:\Python26\lib\site-packages\django\core\management\base.py",
line 222, in execute
output = self.handle(*args, **options)
  File "C:\Python26\lib\site-packages\django\core\management\base.py",
line 351, in handle
return self.handle_noargs(**options)
  File
"C:\Python26\lib\site-packages\django\core\management\commands\syncdb.py
", line 99, in handle_noargs
emit_post_sync_signal(created_models, verbosity, interactive)
  File "C:\Python26\lib\site-packages\django\core\management\sql.py",
line 205, in emit_post_sync_signal
interactive=interactive)
  File "C:\Python26\lib\site-packages\django\dispatch\dispatcher.py",
line 166, in send
response = receiver(signal=self, sender=sender, **named)
  File
"C:\Python26\lib\site-packages\django\contrib\contenttypes\management.py
", line 28, in update_contenttypes
ct.save()
  File "C:\Python26\lib\site-packages\django\db\models\base.py", line
410, in save
self.save_base(force_insert=force_insert, force_update=force_update)
  File "C:\Python26\lib\site-packages\django\db\models\base.py", line
495, in save_base
result = manager._insert(values, return_id=update_pk)
  File "C:\Python26\lib\site-packages\django\db\models\manager.py", line
177, in _insert
return insert_query(self.model, values, **kwargs)
  File "C:\Python26\lib\site-packages\django\db\models\query.py", line
1087, in insert_query
return query.execute_sql(return_id)
  File
"C:\Python26\lib\site-packages\django\db\models\sql\subqueries.py", line
320, in execute_sql
cursor = super(InsertQuery, self).execute_sql(None)
  File "C:\Python26\lib\site-packages\django\db\models\sql\query.py",
line 2369, in execute_sql
cursor.execute(sql, params)
  File "C:\Python26\lib\site-packages\django\db\backends\util.py", line
19, in execute
return self.cursor.execute(sql, params)
psycopg2.DataError: value too long for type character varying(100)


The error can be eliminated if the .only() method is not used:

#for subtype in type_entity.objects.all().only('slug'):
for subtype in type_entity.objects.all():


The tests complete without error when changing the above line to not use
.only().

Other output from the various print statements in update_contenttypes 
(note the last model listed):

RE: Permission model's CharField fields, name and codename, too short

[Giovannetti, Mark]

 

> -Original Message-
> From: django-users@googlegroups.com 
> [mailto:django-us...@googlegroups.com] On Behalf Of Malcolm Tredinnick
> Sent: March 19, 2009 22:18
> To: django-users@googlegroups.com
> Subject: Re: Permission model's CharField fields, name and 
> codename, too short
> 
> 
> On Thu, 2009-03-19 at 21:58 -0400, Giovannetti, Mark wrote:
> > Hi Everyone,
> > 
> > Has anyone else run across this?  I tried to enter it as
> > a ticket at: 
> > 
> >  http://code.djangoproject.com/simpleticket
> > 
> > but was mistaken for a spammer.  ;-)
> 
> You need to register then, as it says in the big coloured box on that
> page.

I saw that, thank you.  I declined registration for reasons of
my own.

> 
> I was hoping your mail would finish with "so I decided to check if the
> ticket was already in Trac and realised it was #8632".

I saw a few other related tickets as well.

> 
> I found that by typing "Django long permission names" into 
> Google and it
> was the first link. Please, please, please search before opening
> tickets. There's a good chance it's been discovered before.

Yes, the search I performed turned up a few others, too.
One was two years old, the other is 7 months old.

My point in posting is to raise this seemingly simple
issue and have it fixed once and for all.  It is vexing
having to modify the django/contrib/auth/models.py file
on all upgrades to handle this.  

Now, if you have any helpful comments on my original 
questions (below), please provide them.  Thanks.

Original questions:
> I can easily fix this by changing the max_length 
> values both to 255 (in the installed source code and the database) 
> to overcome this.   Should I be doing this?  

I asked the above "should I?" in case the law of unintended consequences
decides to express itself.

and

> If so, can these values be bumped up in the official release?

I asked that question to add it to the request queue to fix this
problem.  

Regards,
Mark


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Permission model's CharField fields, name and codename, too short

[Giovannetti, Mark]

Hi Everyone,

Has anyone else run across this?  I tried to enter it as
a ticket at: 

 http://code.djangoproject.com/simpleticket

but was mistaken for a spammer.  ;-)

Django versions 1.0.x through 1.1 alpha 1, PostgreSQL 8.3.5,
Python 2.5.2

django/contrib/auth/models.py

I have long model names.  I am aware that postgresql has a 128
character limit for tables.  I don't think there is any
practical limit in python to a class name's length.

My problem is:

The definition of the name and codename fields within the
Permission model specify 50 and 100 character limits, 
respectively.

For an app that has a model name of
AgreementGeographicBoundaryApplicability,
the permission name becomes:

Can change agreement geographic boundary applicability

which is 55 characters and generates a database overflow error
(shown below).  I can easily fix this by changing the max_length 
values both to 255 (in the installed source code and the database) 
to overcome this.   Should I be doing this?  If so, can these values
be bumped up in the official release?

I.e. change the Permission class' field definitions to:
{{{
name = models.CharField(_('name'), max_length=255)
content_type = models.ForeignKey(ContentType)
codename = models.CharField(_('codename'), max_length=255)

}}}

running manage.py test
{{{ 
Creating table pdf_...
Permission generation starts next:
Traceback (most recent call last):
  File "manage.py", line 11, in 
execute_manager(settings)
  File
"/usr/local/lib/python2.5/site-packages/django/core/management/__init__.
py", line 350, in execute_manager
utility.execute()
  File
"/usr/local/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/local/lib/python2.5/site-packages/django/core/management/base.py",
line 195, in run_from_argv
self.execute(*args, **options.__dict__)
  File
"/usr/local/lib/python2.5/site-packages/django/core/management/base.py",
line 222, in execute
output = self.handle(*args, **options)
  File
"/usr/local/lib/python2.5/site-packages/django/core/management/commands/
test.py", line 30, in handle
failures = test_runner(test_labels, verbosity=verbosity,
interactive=interactive)
  File "/usr/local/lib/python2.5/site-packages/django/test/simple.py",
line 191, in run_tests
connection.creation.create_test_db(verbosity, autoclobber=not
interactive)
  File
"/usr/local/lib/python2.5/site-packages/django/db/backends/creation.py",
line 316, in create_test_db
call_command('syncdb', verbosity=verbosity, interactive=False)
  File
"/usr/local/lib/python2.5/site-packages/django/core/management/__init__.
py", line 158, in call_command
return klass.execute(*args, **options)
  File
"/usr/local/lib/python2.5/site-packages/django/core/management/base.py",
line 222, in execute
output = self.handle(*args, **options)
  File
"/usr/local/lib/python2.5/site-packages/django/core/management/base.py",
line 351, in handle
return self.handle_noargs(**options)
  File
"/usr/local/lib/python2.5/site-packages/django/core/management/commands/
syncdb.py", line 98, in handle_noargs
emit_post_sync_signal(created_models, verbosity, interactive)
  File
"/usr/local/lib/python2.5/site-packages/django/core/management/sql.py",
line 205, in emit_post_sync_signal
interactive=interactive)
  File
"/usr/local/lib/python2.5/site-packages/django/dispatch/dispatcher.py",
line 148, in send
response = receiver(signal=self, sender=sender, **named)
  File
"/usr/local/lib/python2.5/site-packages/django/contrib/auth/management/_
_init__.py", line 28, in create_permissions
defaults={'name': name, 'content_type': ctype})
  File
"/usr/local/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/local/lib/python2.5/site-packages/django/db/models/query.py", line
372, in get_or_create
obj.save(force_insert=True)
  File
"/usr/local/lib/python2.5/site-packages/django/db/models/base.py", line
328, in save
self.save_base(force_insert=force_insert, force_update=force_update)
  File
"/usr/local/lib/python2.5/site-packages/django/db/models/base.py", line
400, in save_base
result = manager._insert(values, return_id=update_pk)
  File
"/usr/local/lib/python2.5/site-packages/django/db/models/manager.py",
line 144, in _insert
return insert_query(self.model, values, **kwargs)
  File
"/usr/local/lib/python2.5/site-packages/django/db/models/query.py", line
1033, in insert_query
return query.execute_sql(return_id)
  File
"/usr/local/lib/python2.5/site-packages/django/db/models/sql/subqueries.
py", line 317, in execute_sql
cursor = super(InsertQuery, self).execute_sql(None)
  File
"/usr/local/lib/python2.5/site-packages/django/db/models/sql/query.py",
line 2020, in execute_sql
cursor.execute(sql, params)
psycopg2.DataError: value too long for type character varying(50)

Forcing content_types.json to be loaded before any other fixtures

[Giovannetti, Mark]

Is there a way to force a fixture to be loaded first
when running manage.py test?

I'd like to load a content_types.json fixture immediately
before any other fixtures are loaded.  

This might fix some of the vexing problems with using
content_types and tests.

Anyone know if this is possible?

Thanks
Mark

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---