> 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? 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. > General advice would be to name your fixtures after the task the data > contained performs. For example: > - 'initial_data' is all the data your application _must_ have to > operate - default table entries, and the like. > - 'sample_data' could be a selection of sample data (entries in a blog > for example) that allow you to test that your application works > - 'weird_cases' could be a selection of sample data that are edge > cases - e.g., a blog with no entries, or a blog entry with no text This is quite helpful. 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 . Is there any way to optionally break these fixture files down into more manageable chunks? Such as per-model? It would be handy to have initial_data.json # multiple smaller data-sets initial_data.colors.json # akin to the X11 rgb.txt initial_data.makesmodels.json # every known vehicle make/model etc. in a similar fashion to what was done with the initial-sql stuff (for backend-specific SQL, attached to a given model). Otherwise, for a given app, these could grow to an unwieldy size. There might be problems with interplay and sequencing, so it might not be a great idea, or at least one to use with caution. Just a few ideas and questions. Hopefully this thread can help build the foundation on some deeper and more consolidated documentation in the future. Thanks for taking the time to help shed light on it. -tim --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
