If you want automatic storage of nested object, override this.
If you want automatic storage of nested object, override this.
Blech. The typing here is all crazy and this is the only way I could find to make it work properly. It would be ideal to pass in a correct type and get back OpmStorage specific to that type. The problem is that one could potentially call this method to return OpmStorage for any number of different subclasses of OpmObject. I think there's some confusion (in my head, at least) around covariance and contravariance - it's possible this needs V to be covariant, but all of the other places it's used it needs to be either contravariant or invariant. Anyway, I have it expecting a typed obj here purely for typing purposes; as such, it is optional and None can be passed. The type of the returned OpmStorage object is really determined by the manifest, which will oftentimes even override the type of the passed-in obj. If you know how to clean up this mess, please do. But it works as-is and is generally hidden from the end user.
Returns an OpmStorage object for the given type.
Use this to put a batch of changes as a single diff, without losing history.
Use this to put a batch of changes as a single diff, without losing history.
OPM can be a bit verbose when storing diffs as individual records in the database. Use this method to take all of your current unwritten changes, squash them into one single change, then push them to the top of the object's history. For example, imagine your implementation is in Postgres and triggers save off your changes when you update a table.
put would look like this: update my_table set foo = '1' where id = 1234; update my_table set bar = '2' where id = 1234; update my_table set baz = '3' where id = 1234;
but squashPut would look like this: update my_table set foo = '1', bar = '2', baz = '3' where id = 1234;
Document Me.
9/4/12 7:07 PM