For want of an example...
Sep. 11th, 2009 10:19 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
elfsGrrr... 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."
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."
Rails
Date: 2009-09-12 12:48 pm (UTC)So, would that be an example (albeit a trivial one)?
-Michael
Re: Rails
From: