Monthly Archives: December 2009

Magento’s dataHasChangedFor(isDirty)

I just built 4 hours of code on top of isDirty, when I noticed it isn’t even working! I wanted to test if something has changed in the ‘customer_save_before’ event, so I could do something first. But Magento seems to simply not care if an object’s main properties or relations are dirty. It just saves whole object trees, wether something changed or not. AAAAAARGH! Yet another performance penalty, straight from the hip.

Isn’t it basic stuff to have your value container flag properties and itself as dirty? Magento started on isDirty and flagDirty, but didn’t pull through and left it unfinished. Instead they implemented a dummed down method called “hasDataChangedFor”, which doesn’t allow for testing if the object itself is dirty or not (because one of its properties is). I notice that it’s sparsely used, but not for testing whole objects before they’re saved.

Now I have to create an unnecessary bloated mechanism that goes through each property in getData, and see if it is found in oldData, and then test if it’s changed with hasDataChangedFor. AAW!

I hope the Varien guys pick up on this and start using the dirty pattern, because it’s simply too much to carelessly save whole object trees and make costly database queries when it’s not even needed.

Maybe I am too much of an angry guy right now, instead of a quiet and thorough investigator, so I might have overlooked something here. I hope so. Please tell me if I’m wrong 🙂

UPDATE: it’s even worse than I thought, because in both customer_address_save_before/after, _origData is not populated, so I have no clue wether something about the object has changed or not. Bummer! Does that mean that I have to load up the old objects from the database first? So much overhead, I am getting more even depressed.