On 5/12/07, Tim Chase <[EMAIL PROTECTED]> wrote:
>
> I'm having some difficulty wrapping my head around Django's
> fixtures and am looking for some good ground-up documentation.
> Most of the documentation I've stumbled across seems to describe
> fixtures as if the reader already knows all about them, where to
> stash them, how to create them (either automated'ly or by-hand),
> and where to stash them.
Thanks for the feedback. I agree that we could improve on this area.
There are little bits of fixture-related details spread all over the
docs (django-admin, serialization, testing) - there is definitely room
for a single dedicated document.
> My understanding is that the initial_data fixture is _the_ way to
> load, well, initial data into the DB. I've got some CSV files
> that would make this quite handy (though they'd be easy to
> transform with a little sed/awk/vim into JSON or SQL "INSERT"
> statements, or whatever format is easiest to understand/work-with).
You are correct - initial_data fixtures is the preferred mechanism for
loading data.
We don't currently have support for CSV as a fixture format; however,
if you feel enthused, you should be able to write a CSV serialization
module. Although it sounds daunting, it actually shouldn't be that
hard - you just need to be able to get the CSV into a Python dict with
a particular structure.
If you don't want to go down that path, we do have built in support
for JSON, XML, and YAML; so you will need to get your CSV data into
one of these formats.
> I've gathered that one can create {projname}/{appname}/fixtures/
> directories. Does some sacred-named file go in this directory?
Yes, you can create those directories. You can also put a FIXTURE_DIRS
setting in your settings file, and add any other fixture directory to
the search path.
There is no sacred-name file, though. More on this later.
> According to
>
> http://www.djangoproject.com/documentation/django-admin/#loaddata-fixture-fixture
>
> "each fixture has a unique name", but I'm missing the naming
> conventions if there are any. My guess would be (and given
> Django's sensible design, guesses are often fairly close to being
> right) that one would create files here named after one's models,
> so if you had a projname.appname.models.MyModel one would create
> {projname}/{appname}/fixtures/mymodel.{json,py,sql,txt,csv?} file
> and populate it with the associated'ly formatted data?
The fixture name is a bit like a tag. You can produce multiple files
called 'XXX.json' (or whatever format you want), and put them
throughout your application, in the various fixture directories. Then,
if you sad 'loaddata XXX', Django will find and load _all_ the
fixtures named XXX, wherever they are stored in your application. The
fixture directories under applications are the default contents of the
search path; the contents of FIXTURE_DIRS is added to the search path.
If any of these directories contain a fixture file called XXX, that
fixture will be loaded.
Naming fixtures after models is certainly one option - however, there
isn't anything magic about fixtures named after models. The only magic
name is 'initial_data', because that fixture (however many files it is
distributed over) is loaded during syncdb.
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
I.e., functional, rather than nominative (if you catch my drift).
> I'm also somewhat confused about the interplay between fixtures
> and "initial SQL":
>
> www.djangoproject.com/documentation/model-api#providing-initial-sql-data
>
> Is one better than the other? Are they complementary? Used for
> different purposes? (perhaps "Initial SQL Data" for globally
> initial data, and Fixtures for testing data?)
Initial SQL was the old way of getting data into a project. The
downside is that SQL varies slightly between database backends, so a
Postgres initial SQL block won't usually run on MySQL, and so on. On
top of that, SQL isn't a particularly natural format for describing
raw data. Fixtures let you describe "just the data', and get that data
into you app, regardless of your database backend.
However, Initial SQL still has uses. In particular, if you want to use
some nifty database features, such as triggers, or setting up special
indexes, or modifying the tables that Django produces by default, you
can use initial SQL to modify the tables after they are created. And,
if you have an old app, you can continue to use Initial SQL to load
data into your application.
> Is there some sort of _Django Fixtures for Dummies_ writeup that
> I've missed?
Not so far. As noted before, it is probably worth writing. Feel free
to open a feature request.
Side note: If you want to make a _really_ valuable contribution to
Django, keep notes of everything you find confusing as a newcomer to
fixtures, and write the document yourself. I'd be happy to include it
into the Django official docs so that we can fill this particular
documentation hole. At the very least, please provide a list of things
you think should be addressed by such a document, so that when someone
(probably me) gets around to writing those docs, they know what isn't
obvious.
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
-~----------~----~----~----~------~----~------~--~---
