I often tell people without irony that laziness is my super power. Laziness motivates me to put my efforts into finding ways of getting things done with less effort, to the endless annoyance of those around me who work a lot harder than I do.
> One must beware of anyone who is both stupid and hardworking
Larry Wall: 3 great virtues of a programmer are Laziness, Impatience and Hubris.
Which is both a joke (turning virtue on its head) and kinda true, in that laziness makes you automate things, impatience spurs you to make things faster, and hubris spurs you to make sure that they work.
I’ve always seen the hubris as an essential component of doing things “you didn’t know you couldn’t do.” A lot of great ideas are discounted as impossible and it takes hubris to fly in the face of that perceived impossibility. I reckon most of the time it doesn’t work out and the pessimism was warranted—but those times it does work out make up for it.
I would have expanded on the hubris part. When your laziness and impatience cause you to create something to save you time and effort, your creation will not work the first time (ironclad rule). But hubris makes you think that a little easy tweaking will fix your creation. And hubris fails you every single time, because the "little easy tweaking" eventually turns into a lot of hard work, not to mention hair pulling.
(I'm working right now on a problem my hubris caused me; a variable stored in a database seems to have different values depending on what part of my code it is queried from. Days I've spent trying to understand what's going on...)
Laziness leads us to conserve resources, and impatience to "save time" (which is a resource, but of a unique nature).
Pride also leads us to make our work more robust, so that it "always works well."
Thus, two fundamental principles are respected: optimization and robustness.
Is your problem related to various parts of the code being in distinct transactions? Can you try a version having all parts commiting then immediately synchronizing with each other, then SELECT'ing?
I found a fix to the problem, although I never quite pinned down why it was necessary. It wasn't a commit problem, but rather had to do with two objects pointing to the same third object as its "parent", whereas the third object only pointed to one of those other two objects as its "daughter". When queried from either object about the third object's daughter, it gave an answer pointing to that object, despite the parent pointing to just one of the two objects. The fix was to make the non-owned object point to a different owner. But I still am not clear why that was necessary.
> One must beware of anyone who is both stupid and hardworking
Oh, so true.