[cap-talk] capabilities for databases and database-like systems

[Jonathan S. Shapiro]

On Tue, 2005-04-19 at 12:40 +0100, Ben Laurie wrote:
> I don't see why - if it makes sense to insert rows in a view that 
> removes columns, that can only be so if the values for the hidden 
> columns can be deduced from the visible ones plus context, surely?

Indeed, but in this case any database schema that actually stores those
columns is making a mistake -- they should have been computed -- and
further there was no motivation for hiding them in the view because the
contained no marginal information.

> I will readily agree that you can't do this in general, but in cases 
> where you can't, then insert is simply not a valid operation.

Yes. That was my point. I haven't thought this through, but there would
appear to be two kinds of views in the world:

1. Filters -- content in a row is not obscured, but some rows may not be
shown.

2. Selectors -- some content in displayed rows may not be revealed.

If, for a moment, we consider only filters, then there is a further
concern: two views on two different tables may not reveal a consistent
subgraph of the object graph, because the filter may result in occluded
joins.

What I'm trying for here is to understand what conditions have to apply
in order for views to be treated generally, and I haven't got a handle
on it yet.

shap