I'll expand on my iphone post with some pseudo-code. do blocks make a convenient way to express the concept of a group of actions. using this, we can implement simple, behind-the-scenes atomic storage semantics. note that I'm (mis)treating saveable as both some reference into the database, and it's value.
function atomic_action(callable, saveable) old_row = copy(saveable) lock_row(saveable) try callable(saveable) save_row(saveable - old_row) finally unlock_row(saveable) end end function eager_atomic_action(callable, saveable) old_saveable = get_current(saveable) callable(saveable) lock_row(saveable) try assert_that( old_saveable == get_current(saveable)) save_row(saveable) finally unlock_row(savable) end end atomic_action(a) do b b.x += 2 end # b.x is saved here, unless we threw an error On Tue, Mar 25, 2014 at 10:57 PM, Stefan Karpinski <ste...@karpinski.org> wrote: > On Tue, Mar 25, 2014 at 8:11 PM, Keith Mason <desc...@gmail.com> wrote: >> >> Got it, thanks. In these terms, I guess I wish that there was an option >> for mutable composite types to be stored inline rather than heap allocated. > > > That's often called a (mutable) value type. E.g. C# distinguishes reference > types – objects that are passed and assigned by reference/sharing – from > value types, which are like C structs and are passed and assigned by > copying. (If you think of reference types as pointers to objects, you're > basically right). Rather than introducing two radically semantically > different kinds of types, we opted for mutable versus immutable which have > the same semantics except for the obvious difference that you can't mutate > an immutable value. This distinction is much simpler to understand and nice > for lots of things, but it is occasionally limiting. > >> Anyway, this has been helpful, if only to confirm that there isn't a great >> way to do what I want. I need to rethink the problem space. > > > Have you considered column-oriented storage where each column is homogenous > and can be mmapped?