#7052: auth fixture fails to import when running test server
------------------------------------+---------------------------------------
Reporter: jb0t | Owner: nobody
Status: new | Milestone:
Component: Serialization | Version: SVN
Resolution: | Keywords: auth_permission
auth_content fixture import
Stage: Accepted | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
------------------------------------+---------------------------------------
Comment (by shai):
I think I have a usable workaround. The idea is simple: Allow each class
to set its own content_type id.
To do this, we connect a function to the pre_save signal of !ContentType;
this allows us to modify !ContentType instances before they are saved. We
make the function take an id for the content_type from the model class.
At the top of the models.py file, after imports, add these lines:
{{{
# Make content_type ids consistent
from django.db.models.signals import pre_save
def set_content_type_id(sender, **kwargs):
content_type = kwargs.get('instance')
if content_type is None:
raise Exception, "pre-save signal API changed -- fix me"
cls = content_type.model_class()
if getattr(cls,'content_type_id',False):
content_type.pk = cls.content_type_id
pre_save.connect(set_content_type_id, sender=ContentType)
}}}
Now, in each model class, you can add an attribute like so
{{{
class MyModel(models.Model):
...
content_type_id = 2001
...
class MyOtherModel(models.Model):
...
content_type_id = 2002
....
}}}
Classes which do not set the content_type_id will have one assigned to
them automatically (in sequence).
This is still not perfect -- it places the burden of allocating unique ids
on the programmers, rather than the system, but it is still way better
than having to manually edit dump files every time.
A note about picking ids: In most cases, you do not need to set ids for
all models, and you have less than, say, 200 models, so ids over 1000
should be safe (you can use ids up to a billion or two, so there's really
no problem there). Just be careful if your ids sequence is not reset when
you recreate the database -- then your ids will just grow and grow. In
such a case, I would allocate low numbers and define the sequence to start
higher.
Another note: This workaround could lead to a real solution; if the ids,
instead of being set by the user, were being set from some hashing of the
model name. But there are several problems in this direction: One is
finding a hash function that's platform-independent, and a much harder one
is finding a conflict-resolution method that guarantees no change when
models are added. These are hard problems, and for me the benefit doesn't
seem to be worth the effort.
A final note: My first instinct was to add the content_type_id to a Meta
nested class, rather than the class itself. Alas, Meta does not allow
addition of arbitrary attributes. Perhaps the content_type framework needs
a helper-class system like the admin framework's, but for just one
attribute, it (again) isn't worth it.
Hope this helps,
Shai.
--
Ticket URL: <http://code.djangoproject.com/ticket/7052#comment:10>
Django Code <http://code.djangoproject.com/>
The web framework for perfectionists with deadlines
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" 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-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
