Comments for Jeff Blaine

Comment on Django: Taking note of ManyToManyField changes by Jeff Blaine

Jeff Blaine — Tue, 24 Jan 2012 21:15:00 +0000

Here’s what I ended up doing today to address this as best as I can, even though it is inefficient to do:

def resave_bc_m2m_changed(sender, **kwargs):
a = kwargs['action']
if a == ‘post_add’ or a == ‘post_remove’:
kwargs['instance'].save()
# Don’t do anything in pre/post_clear
# for this effort

m2m_changed.connect(resave_bc_m2m_changed,
sender=Netgroup.interfaces.through,
weak=False)
m2m_changed.connect(resave_bc_m2m_changed,
sender=NetgroupContainer.members.through,
weak=False)

Comment on Django: Taking note of ManyToManyField changes by Jeff Blaine

Jeff Blaine — Sun, 22 Jan 2012 22:45:00 +0000

Reinout van Rees writes about his workaround here: http://reinout.vanrees.org/weblog/2011/11/29/many-to-many-field-save-method.html , which seems to essentially be what Jay has suggested above.

Comment on Django: Taking note of ManyToManyField changes by Jay Wineinger

Jay Wineinger — Fri, 20 Jan 2012 18:00:00 +0000

As an off-the-cuff solution, you might be able to create a ModelForm and override save to calculate the changed M2M values before calling super(…). You would need to retrieve the current DB values for the M2M, compare them to the form’s cleaned_data, and calculate the set difference. I would call super and then send a custom signal with your changed M2M values. You should be able to use the ModelForm for the admin and any other custom forms.

As to the failure of solutions 1 and 2, I believe they don’t work because saving the model instance and saving the M2M data are separate. Thus, overriding save() and listening to post_save() will only have the old M2M data available. Since M2Ms require all objects to have an ID/PK for the join table, this seems to be a necessity.

Comment on Django: Taking note of ManyToManyField changes by Jeff Blaine

Jeff Blaine — Thu, 19 Jan 2012 20:53:00 +0000

I’d like to add that this situation exists in 1.3.1 and 1.4-alpha-1 as well. I have found no way to consistently and accurately determine, via model methods or signals, what m2m data has changed.

Comment on Graphite for RHEL 5.7 by Jeff Blaine

Jeff Blaine — Wed, 02 Nov 2011 13:56:00 +0000

Thanks for commenting here Dan. I may go that route. I saw in the dep list of the official Graphite documentation “Python 2.4 or higher (2.6 recommended)” and just bailed on what I figured was going to be an inevitably failed package-based install of all of the pieces. I may redo the effort using RHEL5′s Python 2.4 after we’ve played with it a bit, or maybe just finally get a RHEL6 image finalized for our environment.

Others reading this post + comments may also be interested in https://gist.github.com/889297

Comment on Graphite for RHEL 5.7 by Anonymous

Anonymous — Wed, 02 Nov 2011 10:02:00 +0000

You might be interested in these RPMs: https://github.com/dcarley/graphite-rpms

The only essential dependency on EL5 that isn’t fulfilled by the stock CentOS and EPEL repositories is python-twisted-core, which can be easily rebuilt from the EL6 sources.

Comment on Imagine Language Consolidation by Jeff Blaine

Jeff Blaine — Fri, 22 Jul 2011 15:18:00 +0000

Hi Michael, thanks for reading and replying.

That’s the argument I’ve heard. I don’t disagree with you. It’s tricky this cost vs. actual reward thing, though, especially when both are very seldom honestly and critically judged (because of human nature). The significant innovation of Ruby/Perl/Python compared to Ruby/Perl/Python is pretty hard to enumerate for me. They all do the same thing in insignificantly different ways, and it’s all the same stuff you could do in LISP 20+ years ago.

Remember too though that constraints are an amazing catalyst for innovation.

Yeah, this is a huge multi-faceted and messy topic. I’m sure you and I could spend hours with it :)

Comment on Imagine Language Consolidation by Michael Conigliaro

Michael Conigliaro — Fri, 22 Jul 2011 04:33:00 +0000

I’ve had similar thoughts in the past, but I also think the diversity of languages is good for innovation. To think of it another way, what if we all decided to standardize on PHP 10 years ago? ;-) I highly doubt PHP could have ever evolved to be as powerful as the Python or Ruby we have today.

Comment on On Home Renovation by Jeremy Maziarz

Jeremy Maziarz — Mon, 27 Jun 2011 16:45:00 +0000

Nice save. I like how you were determined not to let the door win. Having that attitude sometimes triggers something in your brain to be inventive.

I had a similar situation a few years ago with a hole saw. Stupidly, I used the wrong size (fortunately smaller)! What saved me was the scrap of plywood I was using to test hole sizes before drilling into the real piece. I centered the hole from the next size up over the smaller hole, clamped it in place and re-drilled a nice clean hole.

Comment on The Big 3 OSS Configuration Management Tool Dependencies by JB

JB — Thu, 17 Feb 2011 21:39:28 +0000

Thanks Alex – I’ve added a “MANY more?” item to the table with an X for Chef and footnote.