id summary reporter owner description type status priority milestone component resolution keywords cc parents 711 Switch unit tests to using in-memory sqlite databases Christopher Allan Webber "At the moment, running tests that don't use a full mediagoblin app are fast, ones that do are slow. Probably the reason for this is that we use 3 sqlite databases (one for celery, one for Kombu, one for mediagoblin itself). I'm not sure whether the celery of kombu (which isn't used during tests anyway) databases would be affected by unit tests if we just switched them over to an in-memory database. It might be easy enough to just do those and they'd be just fine. I don't know. MediaGoblin's db is a bit different because it needs to run the migration machinery to init the db. This means that things will be a bit tricky: Somehow we need to create a reference to the database *before* the MediaGoblin application spins up and connects it to the ORM. Then we need to pass that database connection (without the ORM initialized) to the migrations, then pass it into the MediaGoblin application, which must then connect the ORM to the database based on init. Problem: we set up MediaGoblin's application wrapped in paste, so we don't have much control over this. Here's an alternate solution, also evil, maybe even more so: MediaGoblin the application itself could contain a config option where it will, on init, run dbupdate from *within itself* if needed. (Note: that *could* be used in production environments also but I think it would more likely than not, especially if a person is both running MediaGoblin *and* celery, shoot us in the foot.)" enhancement closed minor 0.5.0 programming fixed Elrond