2012/7/26 Anssi Kääriäinen <[email protected]> > On 26 heinä, 15:44, Danilo Bargen <[email protected]> wrote: > > As the Tickethttps://code.djangoproject.com/ticket/16550is closed, I > will > > continue the discussion here on the mailing list. > > > > The reason for the ticket is that the Django test runner does not > provide a > > way to run custom SQL. This makes sense when users want to load custom > SQL > > *data*, but not when modifying the way the database works. > > > > Here's my comment from the issue comment thread: > > > > I agree very much with the comment above, in that there should be a way > to > > execute custom SQL before and after running syncdb. This should not be > used > > to load custom data, which is truncated anyways, but to alter the schema, > > create new types or load extensions. > > > > In my case, I have to load the Postgres citext extension: > > > > CREATE EXTENSION IF NOT EXISTS citext; > > > > Because I have to create a database manually before running syncdb, I can > > run my custom SQL in my database and then use it normally with Django. > But > > because the extensions are database specific, when running the tests > (which > > create their own database) they fail because the extension is not > present. > > This means that contrary to the comment by russellm, the *test database* > > introduces an inconsistency between the way tables work during a test > case > > and the way they work in production. > > > > Another widely used extension is the hstore extension. > > > > As a workaround, I loaded the extension in the default postgres template. > > > > psql -d template1 -c 'CREATE EXTENSION citext;' > > > > But that means that any new database I create will contain the citext > > extension, which might not be what I want. > > Therefore I suggest that you add some pre syncdb and post syncdb hooks to > > run custom SQL, and to mention in the docs that this should *not* be used > > to load custom data, but to create new types and alter the schema, so > that > > it *matches the production database*. The data is truncated anyways. > > > > I vote for reopen. > > > > What do you think about this issue? Does anyone else agree that there > > should be a way to run custom SQL in order not to create inconsistencies > > between the test and production database? > > I agree, the ability to run raw SQL on syncdb would be useful to me. > > There is an idea for allowing post_sync SQL for models (see > > http://groups.google.com/group/django-developers/browse_thread/thread/2a1b068f56faae75 > ). > It is clear one might want to define something else than post-sync SQL > per model. The full set of hooks seems to be: > - per project (pre + post) > - per app (pre + post). > - per model (per + post) > I wonder if we want to support all of those... >
I think all three are useful, but I think the most useful: per model and per project. > > The main gripe against any of the above is that once you start doing > schema migrations, then you need to define the raw SQL in multiple > places. Both in the app and in the migrations files. This raises the > question if migration files is the right place to do this to begin > with. The syntax could be something like: > > class Migration: > apply_at = 'pre_sync'/'post_sync'/'migrate' > > Where 'migrate' is the default and means the migration is only applied > on "manage.py migrate". pre_sync and post_sync would be applied on > syncdb, and also on migrate if they are not applied before to the DB. > The idea is that you could define the raw SQL only once, and it would > be applied both to testdb on sync, and to production db on migrate. > > Still another idea: maybe we want to take the easy route and add > special "pre_sync/post_sync" initial SQL file names. Document that > these files should not contain data, just schema definition. Once we > get the migrations framework in, then deprecate the whole "initial SQL > in a directory" concept. > Having the hooks as a method or function, I find it much more interesting than having them in files. Above that allows logic in these methods, which with flat files is not possible. > > - Anssi Andrey. -- Andrei Antoukh - <[email protected]> http://www.niwi.be/page/about/ http://www.kaleidos.net/A5694F/ "Linux is for people who hate Windows, BSD is for people who love UNIX" "Social Engineer -> Because there is no patch for human stupidity" -- You received this message because you are subscribed to the Google Groups "Django developers" 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-developers?hl=en.
