On 8/14/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > > I asked this before and no one answered, but after having to do this > manually in the shell for about the fifteenth time, I'm going to ask > again.
Can't say I remember seeing this question the first time round. Apologies for missing it. > Let me outline what I'm doing and see if I'm doing something wrong: ... > This last step changes the id of the old permissions and my serialized > test data no longer sets the permissions it's supposed to. Now I have to > remake my test data. > > Is this a real problem, or am I just making it up? This could be a real problem. Permissions are all based on ContentTypes, and the ID's assigned to contenttypes will depend on the order in which applications are installed. The same problem will potentially exist with GenericRelations, or anything else relying on ContentType references. Changing the order of the INSTALLED_APPS shouldn't cause this problem (if you can demonstrate that it does, there might be another issue at work here). Adding a new application by itself shouldn't cause a problem either - the new permission ID's should be added with sequential IDs at the end of the existing IDs. However, the following sequence will cause problems: - Add two applications, and sync - Write a fixture that uses permissions for those apps - Add a third application - Write a fixture that uses permissions on the third app - Destroy and recreate the database In this case, there is no guarantee that the permissions will be recreated in the same order as they were in the first instance - hence, serialization problems. Does this correspond with the use case you are seeing? Or are your serialization problems more widespread than this example? > If it's a real problem, is there a way around it? Since fixtures are > such an easy way to create test data, it would seem a really good idea > if they supported the ability to create data that wouldn't break > unnecessarily as a result of a project just evolving. I agree that this is annoying. One possible way around the problem is to serialize your ContentTypes. This will ensure that the content types in any new database correspond to their original values. This will require your to rebuild your contenttype fixture every time you add an new application, but this is fairly easy to do with ./manage.py dumpdata contenttype The only permanent solution I can think of would be to introduce some sort of query language into the fixtures, which is a road I'd rather not travel down. Any other suggestions are welcome. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
