-
Notifications
You must be signed in to change notification settings - Fork 346
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Testing south migrations: always disabled with pytest #128
Comments
I think there might be a historical reason for that, but no, not really that I am aware of. I have a plan and some half-finished stuff in my "fixturefix" branch to refactor the internal django database setup fixtures, which would make customizing any part of the database setup easily swappable. I think running migrations will be very trivial to add to a project when that is possible. My plan is to finalize the fixturefix work on the EuroPython 2014 sprints, and any help with code and/or feedback would be very welcome. If my ideas about that turns out to be too tricky/too long in the future, we could possibly go for a simpler fix for this specific use case. |
Sounds good. I'll be also at EuroPython. Please take a look at #127 also: does this fix make sense with regard to your changes? Are you referring to this branch: https://github.com/pelme/pytest_django/tree/fixturefix - it appears to quite different from master (missing commits from master)?! (https://github.com/pelme/pytest_django/compare/fixturefix) |
The fixturefix branch has not been synced to master in a bit and is a bit painful since it changes much internals. It is probably possible to break it up into smaller pieces and have those merged to master earlier. I just started playing with some ideas in that branch... and then in it grew. :) The main idea is that customization such as running migrations (this issue), using Postgres COPY command (#38), using the same database name for all xdist processes (#98), control database reuse on any level (#74), put objects in the database right after db creation and commit them (#105) shall all be very easy to achieve. There are more related issues too with the same theme: changing the way the database is constructed. Adding a lot of flags and/or settings for each case in pytest-django will be very hard to support. The "user code" required to do these things will be to implement a fixture which basically just calls for instance I realize I haven't communicated these efforts properly, but I intend to finalize the ideas and code in that branch during the EP sprints where more people can get together in person and discuss the ideas. This commit also gives some hints about my ideas: |
@pelme |
Good, let me know if you have any feedback/questions about it. I am currently a bit overwhelmed with work and other things but will try to respond as fast as possible. :-) |
I just realized that this issue has been discussed before: #22 I think that the current monkey patching way has its origins before south introduced Monkey patching syncdb the way it's currently done is just ugly, and I don't think this change needs to wait for the planned refactor. We should make sure to show |
This is fixed and merged into master as of be3057e |
The documentation states:
It there a particular reason for this?
South supports the setting
SOUTH_TESTS_MIGRATE = False
to disable them btw.Ref: https://github.com/blueyed/pytest_django/blob/db-access-not-allowed-with-both-transdb-and-db/pytest_django/fixtures.py#L41-44
The text was updated successfully, but these errors were encountered: