Supposedly view() is "The normal way to retrieve an existing view." But
apparently even if the view doesn't exist, something gets retrieved --
though it isn't of much use. However, it does appear that you can append
to this non-existent view since
v = db.view('NonExistentView') v.append(foo=1)
*appears* to work. But then, of course any attempt at referencing v[0].foo
fails (though referencing v[0] does not). Shouldn't appending to a
non-existent view raise an exception? If you look at db.properties() there
again *appears* to be a view called 'NonExistentView' there.
How can I tell that I've "retrieved" a non-existent view as opposed to,
say, a merely empty one? If I try to use description() on a non-existent
view I get a really ugly Python internal error.
Given this, what is the point of view()? (No pun intended.)
It's historical: getas used to be very expensive. And there used to be "storeas". Nowadays, like you I tend to use getas all the time. The app essentially says: get me a view of such-and-such shape. Just do it, make it that shape if need be. Extremely handy for adding properties over time.
The future of this is going to be different still, btw. The plan is to treat view structure as a "meta view" itself. So you'll have a view, where each row describes a column.
I started on that in the current MK design, but it really goes much deeper and benefits from a fundamental switch to this approach in the core. That will go as far as making a row add in the meta view be equivalent to defining a new column, and so on for renames and deletes.
But why not raise an exception if a bogus view name is given to view()?
Good point. I think it would indeed help avoid time-wasting surprises.
-jcw
_____________________________________________ Metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
