#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):

 Replying to [comment:11 russellm]:
 > Replying to [comment:10 shai]:
 > > I think I have a usable workaround. The idea is simple: Allow each
 class to set its own content_type id.
 >
 > Ok - so what content type should django-tagging use for a tag? How does
 the author of django-tagging prevent a clash with the content type for a
 blog entry in coltrane?
 >

 I said "workaround", not "solution". You are right; this is not
 particularly useful for reusable, "component" applications (I can think of
 ways -- like using a "base value" for the app, configured at the server
 level, and setting the model content_type ids as offsets from this base
 value -- but this is still not a good way to do things).

 However, for "system" applications -- applications that are not intended
 to be reused as components -- this is workable. It will make jb0t's life a
 lot easier.

 > you have just created a global namespace

 Em, no. content_types did that. And while it did take care to avoid
 clashes, it didn't make the namespace properly (reproducibly)
 serializable. I'm just taking the other side of the trade-off -- clash
 avoidance responsibility to the user, in return for reproducible
 serializability.

 But yes, I agree; this is still quite far from a proper, complete
 solution. It is a partial workaround only.

 (It does hint to the real solution: Make the model name -- probably fully
 prefixed -- the pk of content_type. Yes, a string pk. Blasphemy. I know).

-- 
Ticket URL: <http://code.djangoproject.com/ticket/7052#comment:12>
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to