Comments on: Making history explicit

By: Scott Bellware

Scott Bellware — Fri, 17 Sep 2010 17:21:34 +0000

Just musing to myself that if you guys had gone with a compositional language, that this problem would have been much easier to solve. Just wondering why we constrain ourselves to tools that often have stark limits and then struggle to do things with them that point to tools without these limits.

In a compositional language, so much more is available as standard work. That because more generalized solutions are possible. That’s because there’s no tripping on inheritance of templated types, which are difficult to share effectively across an entire ecosystem.

Here’s how much work this would be in a compositional language, for example, in Ruby:

class Cage < < ActiveRecord::Base
versioned
end

(see: http://github.com/laserlemon/vestal_versions/blob/master/README.rdoc)

Because compositional languages allow many avenues to generalization, these problems get solved early and are made available as ecosystem standard work, eg: http://ruby-toolbox.com/categories/activerecord_versioning.html

What is it that is compelling about the platform you’re using that would see to the re-creation and re-learning of things that are essentially standard work that has been commoditized as plugins and microframeworks?

Is Silverlight really so unique in its capabilities that it is uniquely able to address the line of business user interface issues for your app? It seems like a hell of a lot to trade off to eschew the incredible amount of off-the-shelf components in compositional language ecosystems.

The cost of rework of so much standardized work would have to be offset by some incredible productivity and competitive advantages. Based on what we see regularly in terms of capabilities of contemporary web apps, what is it that you guys are doing with Silverlight – that justifies so much re-invention – that can’t be done with contemporary web development?

By: Josh

Josh — Wed, 15 Sep 2010 22:26:40 +0000

Event sourcing is good, but I hate how everyone jumps to it immediately as “the” only temporal solution.

By: Gabriel N. Schenker

Gabriel N. Schenker — Wed, 15 Sep 2010 19:45:12 +0000

@Josh: we did consider using inheritance but then preferred not to use it. There have been various reasons to do so, one of them being not to have to deal with deep hierarchies which tend to be brittle.
@Josh and Carl: Whenever the schema changes we have to change not only the entity but also the UI amongst other things. Such a change usually affects all layers of an application.
Why didn’t we go with event sourcing? Well our solution is very large and has a long history. We have to consider a lot of “legacy stuff”. It is the typical slow migration to a “better” architectur…

By: Carl Hörberg

Carl Hörberg — Wed, 15 Sep 2010 18:59:59 +0000

Why didnt you go with event sourcing?

How will you handle schema changes?

By: Josh

Josh — Wed, 15 Sep 2010 15:32:34 +0000

Did you ever explore using inheritence for your history object (CageHistory : Cage) so you don’t have to worry about forgetting to maintain new properties that are essentially the same, on two different classes?

By: Gabriel N. Schenker

Gabriel N. Schenker — Wed, 15 Sep 2010 11:56:22 +0000

@J Healy, @Jonathan: we are actually using CQRS in our solution. But you guys are probably talking of event sourcing, isn’t it?
@Jonathan: you can never avoid that a “malicious” DBA manually alters your data but you can at least try to make it as unlikely as possible by declaring in the contract/license that manually changing data is not allowed and violates the contract.

By: Jonathan Oliver

Jonathan Oliver — Wed, 15 Sep 2010 11:23:37 +0000

+1 for CQRS–tracking history and state changes is where it really shines.

Also, how can you 100% guarantee that your audit trail is correct? What happens if someone goes in an edits the table manually (to fix some data that was incorrectly computed because of a bug)?

By: J Healy

J Healy — Wed, 15 Sep 2010 07:28:19 +0000

Looks like a reasonable approach, but my response to such history requirements these days would likely have me leaning more towards a CQRS solution.

By: JeroenH

JeroenH — Wed, 15 Sep 2010 06:06:10 +0000

I’ve done something very similar in the project I’m currently working on.

This seemed like a good idea, but I’m not sure I would model it again like this. In the future, I would probably opt for a simple model for the current situation, and a daily export to a separate table (probably even separate) database. Of course, if you really need the most granular history, this wouldn’t work but in most circumstances it should suffice…