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

 Replying to [comment:12 shai]:
 > 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).

 I have an idea how the solution will work, and I've articulated it before.
 All I need is the time to implement it. Implementing a problematic
 workaround will only serve to consume time that could be spent fixing the
 problem.

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

 content_types namespaces are currently global in the per-app sense. This
 proposal makes them global in the 'whole globe' sense. Per-app, we can
 programatically avoiding collisions. We can't do that over the entire
 globe without the IANA or something similar. String PKs are a non-starter,
 if only because it means a massive backwards change.

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