> > I'll expand on my iphone post with some pseudo-code.
This is interesting; not something I was aware was possible. I'll dig into it a bit deeper, thanks! On Tuesday, March 25, 2014 10:22:48 PM UTC-5, Jameson wrote: > > 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<javascript:>> > wrote: > > On Tue, Mar 25, 2014 at 8:11 PM, Keith Mason > > <des...@gmail.com<javascript:>> > 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? >
