#django

So I'm having some issues with deadlocks when applying migrations to my Postgres database. The migrations in question are all CREATE TABLE (or CREATE UNIQUE, on these newly created tables).

They shouldn't be generating deadlocks, from what I can see.

It's not the same queries they are deadlocking with.

Has anyone else hit this?

Has hand-tweaking my migrations so they are all a single CreateModel (instead of having seperate AddColumn for the FKs) helped cause this?

I read that as "hand-twerking" ... and thought it was some new craze

rofl

So my two planned approaches are to (a) just regenerate the migrations using "makemigrations", and (b) split the migration file into one per operation.

I think the former is nicer, so might try that first.

So, it seems that my combining the AddFields was at least partly complicit.

Regenerating the migrations worked first time.

Lesson learned. Blog post likely.

mmm?

So I was making nice "clean" migrations by moving the AddFields that created FKs into the CreateModel operations.

Seems that maybe it's a deliberate decision to _not_ do that.

ah

I (mistakenly) thought that doing that would make the migrations apply faster and less chance of deadlock.

But it seems otherwise.

MarkusH might know... or andrew

Yeah. It was MarkusH's blog posts that emboldened me to twerk (!!!) them. So I'll blame him ;)

Deferring FK constraints is convenient in most cases, but required in others (circular references)

I thought it was just a side-effect of the CreateModel migration generation happening in alphabetical order.

I think it's more like they get to create them alphabetically because they know the constraints come later.. :)

Perhaps.

I think South might've tried to create tables in the 'right' order and only defer when necessary, but it's been a while.

I might also be thinking of pre-South syncdb. :/

Hahaha.

schinckel: wait, what?

I'm teasing, a little.

schinckel: no, srsly, details please

I ran into an issue where altering migrations (to have fewer operations, by inlining the foreign key fields into the CreateModel statements) resulted in deadlocks.

details

what models did you have

what were your initial migrations and how were the once you optimized?

I might have to PM you the differences in those.

Details will come.

Just in the middle of an email.

k

if you can drop me an example I'll take a look.

But will go to sleep now

Yeah, will do.

hey, is there an easy way to enable plain text password in django admin for user?

as opposed to the hash form

holler: no?

there is no way, since plain text passwords are never stored

You really don't want that.

FunkyBob: I have an admin user that needs to create some other user accounts but he cant enter a plain password for them

what do you suggest

holler: whoever it is didn't read

Hi - I'm implementing Django's password reset and I want to customize the html for them but for some reason it seems that it always wants to use the default html. I tried to create a directory called admin inside of my templates directory and i have my app above the django.contrib.auth in INSTALLED_APPS in settings.py but it still only uses the default html. Any ideas?

well, I've frequently created new users, and admin lets you enter plain passwords on creation

or also offers a password change form

holler: You can _enter_ a password, but it's _never_ stored in plain text.

hm

Rialynn: so which template did you override?

when I try, I set password "temp1234" and click save, on page refresh it still shows "password: temp1234"

dj 1.9

er 1.8

holler: READ THE FINE PRINT... under that field it tells you you can't enter the password there

and then gives you a link to the password change form

FunkyBob: there is no fine print!!! maybe its bc we created custom user

that's probably why

yeah we're missing that

@Koterpillar well ideally all of them but specifically i want to modify the html for password_reset_compete.html

"Raw passwords are not stored, so there is no way to see this user's password, but you can change the password using this form.

"

Rialynn: that template is registration/password_reset_complete.html, not admin/password_reset_compete.html

Rialynn: you need myapp/templates/registration/password_reset_compete.html

holler: Is that a custom form?

schinckel: ya I think

You might want to look at how the auth forms/views work, and make sure you do the same thing.

You can usually just subclass the relevant auth form.

I see.. so you mean subclass some existing auth modeladmin for user?

@Koterpillar That was it. Thank you. I think I had just confused myself a bunch.

holler: Yes.