NoSQL

Yes, it was just a matter of time before I was bitten by the NoSQL bug. What's curious is that I've been a long-time SQL proponent (for my young age) and I think I've managed to grok it over the years. However, the more I deal with relational data in tightly constrained schemas, the more ornery this model seems to be. Just the other day I was dealing with some entity relationships in our project. It's fairly basic and important stuff, like Users that have Roles that have Rights, etc. Thanks to the constraints, adding a few users and roles for the testers turned into an all day chore. Once I had finished with it, I handed it off to another guy who would update the whole entity model along with my data. This caused problems with yet more constraints to other entities. In the end, the whole thing needed to be scrapped as too complex, and the test data never got updated.

I've always just accepted the inherent incompatibility between relational databases and object-oriented languages. Now that I've seen another way of doing it I must admit that I'm rather hooked on a "hash in the sky" so to speak. Why does the data store need to care about every minutia in my data types and properties? It would be one thing if I routinely used a fixed number of strictly typed properties in all my objects, but I don't. I usually have at least some optional properties many of which are intentionally ambiguously typed. Given that, why would I choose a data layer that ties me down so drastically?

In a Bind

Today, I was reading some WPF binding tutorials. This one in particular was somewhat helpful, even if a bit simplistic. One part that amused me was about the binding modes:

"Like OneWay binding, OneTime binding sends data from the source to the target; however, it does this only when the application is started or when the DataContext changes and, as a result, does not listen for change notifications in the source."

Now this is all fine functionality and I'm sure it's nice to be able to do it all The Proper Way. A topic for another post is how WPF tries to be too clean to actually get anything done. To me, it feels a bit like hammering a screw because you've already hammered 50 nails with the hammer you're holding. I know something easier than a one time binding John, no binding at all! Haven't heard of that one? I call it tbColor.Text = "Yellow" and it doesn't require 50k CPU cycles.

Upgrade Woes, Take 2

I've been once again been put into a tough spot by our upgrade policy. Just recently I had to upgrade a client to a build not even a few weeks old in order to give them a bug fix. In case you're wondering why we didn't just patch the branch that they were on, it's because we don't generally do this for branches more than one or two months old. I think this is silly, considering that other ISVs will support a branch with patches and fixes for months or even years. I can't think of another software product released on such an insane build schedule as ours.

Anyway..

Today the customer called in (for the 4th time this week) with another interesting bug. After spending about an hour tweaking a stored proc thinking it was a change I had made two days ago, another guy came and told me that it's likely a code change he included in a couple of builds. It comes as a *complete* surprise that there might be bugs in a new, untested build. The fix, of course, is to put them on a newer build. This build has had even fewer minutes of testing. Any guesses on where this is going?