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?
