Sub context commit

[brummett]

This branch implements a new transaction UR::Context::SyncableTransaction. It allows any changes made while it's in effect to save to the DB without saving changes made outside.

I don't know if this will be the final implementation. It seems a bit hacky to me, and I don't like the name. It probably needs a lot more testing, too.

[nnutter]

What will happen if someone does something bad like create an object before starting a SyncableTransaction and then creates an object that references that first object within the transaction and then tries to commit?

EDIT: Where by reference I am also implying a FK constraint.

[nnutter]

I'm pretty sure this will end up being useful in many places but the one that immediately comes to mind is in Genome::Disk::Allocation where we dynamically construct a Perl script to create an allocation out-of-band. It would probably be worth looking there and making sure this would work.

[brummett]

The commit would fail because of the FK constraint. We can actually have that situation right now if you have an object and fill in the linking ID property with a value that doesn't exist in the FK table.

Another similar situation would be if you create an object outside the SyncableTX, change one of its properties inside the SyncableTX, then commit the SyncableTX. the commit would fail because it would issue an sql 'update' for a row that doesn't yet exists.

I don't think the SyncableTX needs to do anything special to paper over these cases, since it's actually pointing out a programming error.

[nnutter]

What about if you change property foo and then start a SyncableTX and change bar and try to commit. Will just the change to bar be able to go through (assuming no FK constraint)? This is just about shared state outside the SyncableTX.