scratch

Adapter Returns
===============

create(resources)
-----------------

Nothing. Doesn't matter what it returns. In the case of auto-populated fields, the adapter HAS all the records, it can just modify the 
values directly. They don't need to be returned, DM should just update the identity map, and keep using them.

If something bad happens (not created for some reason) that is, and should be, and exception. In the case of DO, the most common case 
would be that you failed some constraint. The app writer needs to know, and be smacked for not having a validation. If they chose not 
to have a validation, then they need to be aware of the dangers. In just about every other case, failure to write is due to something
catastrophic. Disk full, can't connect to the storage engine, etc...

read(query)
-----------

Returns Array of hashes. Can be `{:property_name => value}` or `{Property => value}`.
Alternatively, an array of Resource objects, if for some reason its faster for the adapter to populate them itself.

update(attributes, resources)
-------------------------

We need to change the 2nd parameter from a query to a DM::Collection. If the adapter supports updating multiple records at once, it
can always pull the query out of the collection, and use it as normal.

Providing the resources instead of a query means that an adapter that provides a representation of the updated record can automatically
update the resources in place, just like `#create`. Similarly, it needs to return nothing.

Has the added advantage that most simple adapters run the query by calling #read, then manipulating the results. Since DM has almost
certainly already run the query, we can save that step. If not, its a lazy-loaded collection that might not have been loaded yet, and 
DO adapter can ignore it, and run the query.

delete(resources)
-----------------

Just like update, same rationale. The storage engine may not actually delete it, but instead set a deleted flag, and the adapter can 
populate the resource.