id	summary	reporter	owner	description	type	status	priority	milestone	component	resolution	keywords	cc	parents
679	"Database ""fixtures"" (but not the testing kind)"	Christopher Allan Webber		"(Note: this is *not* the best name, because it could be confused with unit testing fixtures... I don't know if there's a better name that does not have that overlap.)

We're using a relational database, and this means there may be expectations that certain rows are installed in tables.  This could be for several reasons:

* we might have a table that contains different license options; by default, we would want to prepopulate with some good ones
* we might store permissions in the database with certain roles, such as in #678.  But in order to check if someone is in the admin group, that group would need to already exist!
* maybe we could stop storing media type information on media models as a string!  Instead, we could have media types like images, video, etc, on a table.  But that also means that every time we install a media type it needs to set up a fixture in the application for itself.

As far as I can tell, installing fixtures will happen in a couple of ways:
* The first time that mediagoblin core or an extension such as a plugin/media type is installed, it will need to set up some common fixtures.  We need new tooling for this!
* Later, new fixtures may be added or changed.  This is easy; we do not need a new tooling for this, we can use our existing migrations infrastructure.

So in theory, the above two can be handled both by {{{./bin/gmg dbupdate}}}... we just need to add new tooling for the former.

(There's one more possibile tool we could add to this: a convenience method that queries for a certain row, and if it doesn't see it, creates it.  That's not super necessary though.)
"	defect	closed	major	0.5.0	programming	fixed