Going to CouchConf 2011

My employer is sending me to CouchConf in NY this year. I will have both laptops with me at the conference and will be taking notes like a man possessed. Now I just need to find some time to set up CouchDB on my Ubuntu netbook before the trip.

More updates to come!

A (Huge) Needle In A Bigger Haystack

Microsoft's Sync Framework is a fragile creature, and as such doesn't like being abused with data. Today I ran into a problem with our app trying to sync a record that had a field of 8266 characters, which is over the (apparent) 8192 character limit. To simplify the problem of finding which record out of millions scattered across hundreds of tables with dozens of columns, I first hit google like any lazy coder.

This thread got me started by giving me a base for searching a single table for the longest column:
http://www.dbforums.com/microsoft-sql-server/1069468-possible-get-max-length-text-field.html

...but I needed more.

So I wrapped that thing in another cursor, and came up with this:

DECLARE @table SYSNAME, @field SYSNAME


DECLARE b_cursor CURSOR STATIC
FOR
SELECT name FROM sys.tables WHERE name not like '%tracking'  -- customize table SELECTion here
OPEN b_cursor
FETCH NEXT FROM b_cursor INTO @table
WHILE @@FETCH_STATUS = 0
BEGIN


CREATE TABLE #Temp (TableName SYSNAME, ColumnName SYSNAME, MaxLength INT)


DECLARE a_cursor CURSOR STATIC
FOR
SELECT name FROM syscolumns WHERE id = object_id(@table) and name like '%history%' -- customize column SELECTion here
OPEN a_cursor


FETCH NEXT FROM a_cursor INTO @field
WHILE @@FETCH_STATUS = 0
BEGIN
INSERT INTO #temp
EXEC ('SELECT ''' + @table + ''', ''' + @field + ''', max(len(' + @field + ')) FROM ' + @table )
FETCH NEXT FROM a_cursor INTO @field
END


CLOSE a_cursor
DEALLOCATE a_cursor


SELECT * FROM #Temp


DROP TABLE #Temp


FETCH NEXT FROM b_cursor INTO @table
END
CLOSE b_cursor
DEALLOCATE b_cursor


--DROP TABLE #Temp


-- select from a table to see the record with the largest field
SELECT * FROM (SELECT Id, len(History) AS len FROM WorkOrders) AS a ORDER BY len DESC

The guts of it is the EXEC statement that queries each column of each table. Note that I've put in comments where you can customize the queries to filter tables and columns by name, etc. At the bottom is a query that shows how to query a table for records and sort by the record size. Emjoy

** Note: If it complains about the table #Temp already existing, just drop it by running the commented drop statement towards the end.

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.