One of those You-Had-to-be-There moments

Omaha and I took Kouryou-chan out minature golfing last night. It's a cheap pleasure, and Kouryou-chan enjoys it. Somewhere around hole #10 or so, Kouryou-chan took careful aim, swung, bounced the ball off the back bumper and dropped it into right the hole.

"A hole in one!" she shouted, raising her hand and club into the air. I ducked in case it swung back my way. "A hole in one! I got a hole in one! I got a hole in one!" She ran to the hole, shouted one more time "I got a hole in one!" and grabbed for her ball.

"Eewwwww!" she screamed. "There's a slug in there! Gross!"

The sudden change in tenor and action made Omaha and just about die of laughter.

It was a huge slug, too. Why it had chosen an astroturf golf cup is beyond me. We left it alone and played through.

For want of an example...

Grrr... Today, I figured out how to do heterogenous derivative list management in Django, complete with a spiffy rendering technique, without intertwining the classes that contribute to the list with the list itself. The classes exist as Django apps independent of the list, which intertwines the multiple different objects into a rationalized display with different access parameters from those of the classes.

But how do the objects get into the list? Normally, you'd have to mangle them to "push" weak references of their instances into the list-- which might have multiple copies of the weak reference for each permutation of the display parameters. In Django, though, the database layer "publishes" certain events to a centralized manager, and the list manager can set an event listener for a certain event, such as a ClassX.save(), and do something smart with the object just saved.

So the list manager exists independent of the things it lists. Excellent! Even better, by maintaining a consistent interface (a'la Java) for objects the list manager cares about, we can make publishing those objects via HTML or some other deployment strategy trivial.

But I can't come up with a decent example! Other than the obvious one, which would be, er, proprietary information.

A long time ago, I worked for a small bootstrap, much less visionary than this one, and the technology we chose was Forethought's ODBMS, Ft/Ods, an "object-oriented" database written on top of MySQL. The basic premise of ODBMS is that rows in a database not only represent the fields of an object, but also methods-- and when you changed a row, you triggered events that would, in turn, modify other objects.

Our database guy was an idiot, and the intertwining of his classes was so overly complex that a single write would trigger massive cascades that brought a MySQL database to its knees.

I can't help but think that Django signals are a revisit of the ODBMS methodology and its inherent problems. I can easily see, in one project for example, Profiles "watching" Users to ensure that every user gets a profile, and then "friends" watching profiles to make sure that every profile gets an instantiated friends list, and so on, creating massive cascades that disrupt the database server. This is just one example, but if you have a couple of these things on a page-- users, themes, newsfeeds, friends lists, the whole kit and caboodle of modern social web development--

"You're gonna need a bigger boat."