On 5/12/07, Tim Chase <[EMAIL PROTECTED]> wrote: > > > You are correct - initial_data fixtures is the preferred mechanism for > > loading data. > > Okay...things are starting to make a bit more sense. > > I'll post a few more questions and hopefully this thread can > become the foundation for the documentation you describe. > > One of the questions coming to mind would involve > FileField/ImageField and their data in fixtures. Say I have an > PhoneNumberType model for an address-book app, and it has icons > for "Home", "Work", "Cell", "Fax", etc. How would one go about > using initial_data to push the images to the proper places in the > MEDIA dir, and then link their filenames to the associated field > in the fixture file?
Hrm. That's a little harder. The FileField/ImageFields are serialized as the file names, but none of the raw data comes along for the ride. If your MEDIA dir contains all the files you might require, you can serialize/deserialize the database as much as you like; the File/Image fields will keep pointing at the files. However, this doesn't help you move an app from one site to another. I'm open to any suggestions on how this could be acheived efficiently (pickling, or otherwise serializing image data into the fixture probably wouldn't be feasible). > Totally unrelated, to YAML files need a particular extension? > I've seen YAML files with both a .yaml and a .yml extension (darn > DOS 8.3 folks :) Digging through threads on the list, it seems > .yaml is the convention. However, I didn't see anything other > than an oblique reference to YAML on the djangoproject.com site. Django favours .yaml; the file extension on the fixture file must match the name under which the serializer is registered (yaml, xml, json, etc). YAML isn't fully publicised because it's a relatively recent addition (compared to the other serializers), and its not completely 'batteries included' - you need to install PyYAML (http://pyyaml.org) for the YAML serializer to operate. Hence, the docs are lagging behind a bit. > So I put files such as "initial_data.json" in my various > FIXTURE_DIRS of each app to load such data, and then can create > other such fixture-tag-named files (such as sample_data.json) for > testing. This then makes sense in the context of the testing > documentation about associating fixtures with certain tests. Not > all tests need sample data, or some tests might require > pathological test-case data that . Exactly. > Is there any way to optionally break these fixture files down > into more manageable chunks? Such as per-model? At present, no. However, it is an interesting suggestion. Feel free to open an enhancement ticket (and/or work up a patch!) > There might be problems with interplay and sequencing, so it > might not be a great idea, or at least one to use with caution. There shouldn't be a problem with sequencing - all fixtures are installed as a single transaction ,so any ordering issues should be sorted out. The only sequencing problem I can forsee is if two separate fixture files define an object with the same primary key. If this happens, the last one loaded will win, but there won't be an error. 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 [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-users?hl=en -~----------~----~----~----~------~----~------~--~---
