On Fri, Jan 23, 2009 at 5:31 AM, Delta20 <digital_illumin...@yahoo.com> wrote: > > Fixtures are geared towards unit testing; I'm wondering if they are > considered a good way to populate the database with some initial > default values. > > For example, say we have a model TicketState, and the applications > must be guaranteed to have two TicketStates representing the states > "Open" and "Closed", and we want to make it so the user can add more > TicketStates as needed.
This is exactly what the initial_data fixture is designed for. I have used the initial_data fixture in this capacity on several deployed sites. > Is this something that would best be addressed by using fixtures? In > particular, there doesn't seem to be a way to create fixtures > programmaticly (rather than importing JSON or YAML data), which means > that somewhere in the code you would need to have magic values to > refer to the default models that were loaded (a magic value is some > arbitrary string or number, rather than using constants or some other > more controlled approach that is less likely to break later in > mysterious ways). For example: > > # if no state, assign the default state > if not ticket.status: > # Below is bad practice, uses a magic value > ticket.status = TicketStatus.objects.get(name='Open') This is essentially the approach taken by the content_types contrib app. The ContentTypes app uses a management hook (see management.py in the contrib app), which listens for the post_sycndb signal and creates the default content types when that signal is heard. This approach works - although, as you have noted, it does mean you can't rely on the primary key values for any given content type (which, in turn, causes problems for fixtures). ContentTypes optimizes the process slightly by introducing a cache for content type lookups. > Would a different approach be better, such as a having a get_or_create > method that creates the default instance if it doesn't exist already > (rather than using fixtures)? The 'Create on demand' approach would also work, but it might complicate some logic - essentially, no code could ever assume that the default states were available. However, providing you follow through the consequences, it should work fine. 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
