DjangoBot: #django-dev

is it a known bug that calling runserver with call_command makes the code calling it execute twice? (atleast for my management command)

unless i'm doing something wrong

forsaken: i experience that with django_evolution, so I guess it's a bug

whether it has been properly reported, i know not

hrm, okay

it's happening for me as well

so it must be a bug

SmileyChris, have you looked into it at all? or found a workaround?

forsaken: had a quick look but didn't solve it

only happens with runserver, and the runserver inner loop only gets executed once, but yea, i couldn't find anything beyond that

actually, my case isn't identical

state isn't maintained between runs

hrm

there's the example of the behaviour i'm experiencing

running "evolve" works fine (ie only runs once)

dj is an alias there, btw

mine: http://dpaste.com/67344/

forsaken: so, similar

forsaken: seems to be something about signal registration?

yea

not sure really

this is my first foray into much django devel

that's what evolution is using there

i'm guessing so are you

mine isn't using any signals

oh?

just calling call_command('runserver')

and its re-evaluating the containing file

which only gets called once...

yea, but there's code before and after the call that gets run twice

odd

the code before runs twice before the server runs, then the code after runs twice after the server runs

sorry I can't be more help

no worries

i'm not doing anything super important :)

its just odd

agreed

bring it up on the dev group

yea

Hi, is there a reason why signals.post_save is triggered twice for each save?

empty, in your command extensions stuff, did you ever try to call call_command('runserver')?

i see you are copying the code out of runserver instead, i guess because your changing the internals?

I just discussed an issue with many_to_many relationships on #django. assume ive got a 'Survey' model with participants = m2m(User). On creation of the model (e.g. admin interface), i'd like to send each user an email automatically. the trouble is, hooking in post_save does not work, as 'participants' is not populated yet.

One way to go about that would be to move the relation to User

but in this case, that would be difficult

remo: Would creating the intermediary model yourself and than setting up a post_save signal on that work?

If so, #6095 is very close to being committed, perhaps you could test the patch

ah yes, that sounds good

thanks :)

Hi guys, I'd like to discuss #6095. Consider following use-case: I've got a Survey model with Survey.participants = m2m(User), and i want to notify each participant when a survey is created. Now, with the patch, I could define an intermediary model, and hook into its post_save signal to send those messages.

The thing is, defining an intermediary model breaks the admin interface (as participants.add(), .create() etc are blocked). To get an interface like 'filter_horizontal', I'd have to cook up a lot of code.

So, how about we only block the managers .add, .create etc. if the intermediary model defines more fields than the two ForeignKeys? This would allow to hook into the changes of a m2m relation without negative consequences.

remo: what is the point? why just use an m2m without through specified?

oh i think your getting at a completely different issue.

that seems like it would be a good side-affect from 6095

yeah. although hacking the manager to vary on the intermediate model sounds.. hacky ;)

so how would we go about this?

there is an issue in trac that describes adding signals in m2m fields. not sure exactly about its details or whether it would even fix your problem, but sounds more like the correct route.

and of course, i may be off base and your way actually might even be a better use case but not nearly good enough to block it ;)

#6778 really is more reasonable

yeah that is what i was referring to.

as signals is all about hooking in code

ok, i'll see about a patch

cool

hello django devs

do you think that #7560 has a chance to be reviewed on the next week?

that seems to be the only blocker for Django/Jython and would allow me to start writing docs about how to use django with jython, without having to patch anything

so, how do we call those signals? m2m_post_save? and the sender would be the relations manager?

we could also stick with the stock signals

ugh

i forgot about the stupid cull_percentage thing

$%#$!

better

if it's calculated as 1/cull_percentage, it's not a percentage :(