Audit_Strategy

Brainstorming....

Discuss the requirements of auditing changes according to the DB, which requires adding extra queries both before and after each change and not trusting cached/inflated values within the Row objects. However, this obviously comes at a price in terms of overhead. Are there cases where users would prefer to use the values according to the row objects? Should this be an option?

How do we incorporate ResultSet based changes? Do we create Row objects so our Change Context is normalized? (essentially converting $rs->update into $rs->update_all)

Do we want an option to toggle collecting pre-change values? This is redundant for Collectors that already keep track of this themselves.