Enterprise Rails

Hiding the Implementation with the Reconciler View

Now that we have defined our triggers, we have added yet another way for the materialized view to decay. The first decay mechanism was the expiry column, which allows rows to declare when they should be treated as irrelevant. The second mechanism is the dirty column, which our invalidation function sets to true when certain tables receive updates.

Slowly but surely, our materialized view will become a minefield full of stale records we need to avoid if we aim to present accurate data to database clients. Such a table is by no means a drop-in replacement for the original view. Not only is the materialized view slowly turning into garbage but also the interface is different. If selecting directly from this table, a client must be careful to avoid stale or invalid rows. The logic that was neatly contained within the view’s where clause filters is now contained in columns, which the client must explicitly filter on.

We will now plug up these holes, first ensuring that the data returned to clients is always up-to-date. Then we’ll give the original interface provided by the original view back to the client. We’ll hide the dirty and expiry columns and transform the current and sold_out columns back into a filter.

We accomplish the first goal of always returning accurate data with the reconciler view. We give this view the same name as our original, “well-formed” view from Example 12-2, but without the suffix _unmaterialized. It is simply ...