On Tue, 2007-08-14 at 08:27 +0800, Russell Keith-Magee wrote: > 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? > I'm only actually talking about test cases where you start from a fresh database each time. I assume that as you evolve your production database you're smart enough not to, say, serialize the data, rebuild the database willy-nilly, and then cross your fingers and hope the data goes back where it was supposed to. :-)
> > 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. That's something I hadn't thought of, but do you run into trouble because Django creates the content-types itself and then you try to load yours afterward? I was getting weird errors and discovered that the way to solve the problem was to *not* dumpdata auth or any other of Django's own apps. Here's something I considered. What if fixtures were a Python module instead of just a folder and you could include a function as part of a fixture. For example, in addition to test.json, I could include a function called test in fixtures/__init__.py that added stuff to the database using the ORM. Most things would still be done through serialization, because it's so handy, but generic relations and permissions and such could be set with a few lines of Python code. Does that seem like too big a hammer for such a small nail? Todd --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
