#django

schinckel: Any ideas what I'm doing wrong? What information can I show that would help? https://bpaste.net/show/a06cccac666b

The irony is that in 1.5, I had to run migrations with --no-initial-data *every time* to stop south from trying to reload the fixture

Hmm. It looks like it's failing whilst trying to migrate.

What does your first migration file contain?

(I'm about to be away from a computer, so may be of limited help for the next couple of hours though).

i just fought this same issue, basically you can't use fixtures in apps that use new migrations framework

you must replace them with data migrations

lets say I do a = Object.objects.get(id=1)

how do I have it so that when I do a.save(), it saves a duplicate of a?

i want to duplicate a row, slightly modify it, and save it.

im doing some tests buy i get this errors: (traceback) https://dpaste.de/2myi - Can you spot any problem? this is my tests.py: https://github.com/alcance/blog_ng/blob/master/...

Google say set the pk to None.

d0ngz: For the first, you're not setting the slug, so don't know why you'd expect it to be there.

toothe, did you try that?

d0ngz: For the second one, you don't have a view for details of a post, only a list one. You should also avoid building the URL by hand like that in get_absolute_url(): https://docs.djangoproject.com/en/1.7/ref/model...

yelloo

benwilber: that's not true

benwilber: You _can_ use fixtures with the new migrations framework, you just have to declare dependencies correctly and monkey patch something (you should have mock already as a dependency)

benwilber: https://bpaste.net/show/0f9b44c5f952

thanks gcbirzan

schinckel: Ok thanks. (I'll still be here)

benwilber: I see. Does that mean all my migrations will be run every time I run tests?

hackvana: django-nose has a feature that let's you not destroy the DB if it already exists

erm

I mean, it doesn't destroy it at the end of the tests :)

I ended up with nearly 100 South migrations. Assuming I end up with the same number of django migrations, I'd be reluctant to have a system that insisted on running every migration every time.

or at the beginning.

gcbirzan: I see

hackvana: btw, you'll get less migrations, but it'll be waaaaaaaaay slower

I still need to have the database start in a known state, which is why I'm using the fixture

we have 129 migrations and they take 3 minutes and 10 seconds or so on my computer

hackvana: https://bpaste.net/show/0f9b44c5f952

hackvana: You can use that to load fixtures in migrations

I have fixtures which take long than that each. I don't want to lose them (because I often refer back to them), and I don't want to collapse them.

hackvana: What you do is, you run your south migrations, do a dumpdata, drop the DB, run the 1.7 migrations, then craete an empty one that just loads the data you just dumped

That's not possible.

You have to manually re-write them.

I don't mean I need to re-run the South migrations

I mean that for future Django migrations, I don't want to have to re-run them, or collapse them.

gcbirzan: Red that bpaste, where do I put that.

hackvana: You put that anywhere and then use it from a migrations loaddata(apps, 'myfoobar.json')

hackvana: Hm, I don't understand what you mean about future django migrations

"create an empty one" <-- empty migration, or empty something else?

The migrations I write tomorrow and the day after.

Empty migration, yes. ./manage.py makemigrations oneapp --empty

The ones I don't even know I'll be writing.

Ok

You might need to make one for each app that has data, that'll be fun :)

Well, for tests, it's hard.

That's ok

With django-nose, if you have migrations, you drop your DB generally.

One _could_ I guess make it migrate, but meh.

What is "it"?

It only takes 3 minutes here, so it's okay to do it once every couple of minutes

Your test runner

You could write a nose plugin to run call_command("migrate")

I don't want my test running to do migrations. I want it to create an empty database, load my fixture, then start doing tests!

That's not an option anymore.

The tables are created via migrations in 1.7

I mean, not only, but if you want to use migrations, you cannot create tables without migrations

To make matters even _more_ beautiful

django helpfully deletes all the data in the database before running tests

I'm trying to work out which of "One _could_ I guess make it migrate, but meh" and "[load a fixture is] not an option anymore" I like least.

Loading fixutures is an option.

I'm starting to think my tests are where I have to load the fixture :-(

That's one option, but the fixtures will be loaded for each test, which will make it even slower

And, making the tests run migrate is not that hard, it's just (for us) not worth the effort

It's faster than running migrations. The fixture loads in about 3 seconds.

That's not the alternative :)

Test fixtures are not an alternative to migrations, they're an alternative to loaddata in a migration.

Migrations _will_ be ran for tests, if you have any in your app, there's no way around that

Ok, hold that thought. Let's frame it.

Why is my migration (that would create the countries table) not being run? https://bpaste.net/show/a06cccac666b

Because what I'm showing there is running a test, and django is trying to load a fixture, but it's failing because the migration isn't run first.

hackvana: What happens when you do this on the non-test DB?

That's at odds with what you're saying, which is "migrations are run when you test" and "and it's not possible for a fixture to be run when you test". Not your exact words, but it's what I'm hearing

(disclaimer: I'm running this on a test machine with the db loaded with production data, so don't panic)

I expect it will pass, but it will also mess with the production data.

hackvana: The problem seems to be related to flushing the DB after creating it.

hackvana: Might be related to some MySQL weirdness about DDL/transactions?

Can you point me to a line number in my bpaste?

I'll try switching to sqliste

sqlite

File "/home/mjd/git/env-1.7/lib/python2.7/site-packages/django/core/management/commands/flush.py", line 88, in handle_noargs

As it happens, we've overridden flush to not do anything, because it was deleting all the data in the DB before running the tests. Not sure if it works as intended now, I've given up on trying to explain why fixtures are useful to the django devs.

And that RunSQL in the docs thing is just wrong. I want a db-independent way of encoding this data.

hackvana: also, another possibility is that you are actually not creating the table.

That was my question: What is responsible for creating the table? Why is 0001_initial.py (which contains 26 CreateTables) not being called?

What I'd try is to move the initial_data out of the way, then see if the table is created.

The flush should be run after all tables are created, but you might not have the model in there?

Can somebody please tell me how to generate a choicefield in a for loop :/

but, mind you, this is based on 1.7b3 or something when I last looked at this code

hackvana - maybe django think that this migration is already applied?

it might've changed since then