For the moment, a ResultSet contains a list of records which can be stored as is in a database. This is mostly passive usage. For convenience, ResultSets provide the following methods:
iteritems() to loop over the keys _and their content_
view() to create a sorted view of the result set
These methods bind the resultset to the actual database that generated them. If the result sets were completely passive, their implementation could be shared (it is mostly already), and it would simplify the implementation of adapters (one less special case to handle). In order to iterate over results in a result set, users would have to pass along the db with the result set. To create a view, it would be possible to use:
db.view(criterion, resultset=db.entries)
On the other hand, a View has more compelling reasons to have access to the db, as it needs the actual record to keep its content sorted. Views are not permanent, though. But even for ResultSets, how should removals from the db be handled in the result set? If k is in a ResultSet and is removed from the db, is it acceptable that it remains in the ResultSet?
