On Thu, Apr 26, 2012 at 5:08 PM, blais <goo...@furius.ca> wrote: > I receive events from a network. My application calls for storing these > events and doing different things based on the changing status of orders > attached to these events. I need to store them somewhere, I need to track > this state in my app. At one extreme, I could store the changing state near > the leaves (i.e. a list of events by order-id by ...). At another extreme, > I could recreate the entire path of immutable objects all the way to the > root application on every update (using update-in, and with a single ref > for the root application). And then there's all the other options in > between, I could have refs are every level if I chose to (but that seems > very, very wrong, somehow). > > Java would call for mutability at the leaves. > Clojure makes it easy to build it one way or another, but the language is > calling for refs at the root. > > Isn't this a really common case of every type of application out there > which has to store some changing state somewhere? >
You've already stated that your multithreaded needs are modest. Why not one atom wrapping all your data, each piece indexed by the most relevant key, and each actual piece of data is flat. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
