#clojure logs

2008-03-18

01:15arbschtpartial and comp put the fun in functional
11:38ChouserIf I have a nested structure of seqs and maps (a heirarchical database), is there a rule of thumb for what level to put the ref at?
11:39rhickeyis there a known granularity of change? is there an external notion of identity?
11:39Chouserat the very top? farther down at like a "table" level? Are there speed or contention issues I should be thinking about?
11:43rhickeycontention rather than speed should drive it, speed should be fine in any case
11:44rhickeyI would avoid field-level refs
11:44ChouserI've got a map of maps of sets to represent triples, and a second map of maps or sets to represent the inverse. That means that any change to one top-level map will require a change to the other.
11:44Chouserright now I've got a ref for each of those top-level maps.
11:45ChouserI was considering moving it up to the vector that holds that pair.
11:45ChouserI'm not sure what you mean by external identity.
11:46rhickeyoutside of your app, there is a notion that a particular set of data can be identified by a key
11:47rhickeyif you are using triples, probably not an issue
11:47ChouserThere are ids that might be stored outside and used later, but not references to a particular version of the database. Does that answer your question?
11:48rhickeymore to do with object/record identity
11:49rhickeyif you are going to be heavily multithreaded with lots of updates, those top-level refs will be the bottleneck, if any
11:50Chouserok, that makes sense.
11:50ChouserAnd if I always update both at the same time, it won't help any to give each their own ref.
11:51ChouserThe only other place I could put a ref and not be at the record level, would be in the vals of the first map. ...which is an interesting thought.
11:52rhickeyright, you could then update the attribute set for a particular key independently
11:53ChouserI can still sync across multiple, though, to get "atomic" transations.
11:53rhickeyexactly, that's the beauty of STM
11:53rhickeyarbitrary change sets
11:53rhickeyno lock ordering
11:54ChouserSo I would expect this to have thousands of refs. That shouldn't scare me?
11:55rhickeynot at all
11:55Chousergreat.
11:55ChouserI still don't know how I'm going to sync this to disk, but that's a problem for another day...
12:04Chouseroh, but I'll need a ref at the top levels too, since of course you can add keys there.
12:07rhickeyright but you'll only need to use them when you add/remove keys
20:18jmn3hi
20:22jmn3ive been noticing usages of nested [] for bindings. (it was in an fn, actually) Whats that all about? is that mentioned in the docs somewhere?
20:53rhickeyIt's destructuring - documented in the entry for let: http://clojure.sourceforge.net/reference/special_forms.html
21:53jmn3ok thanks
21:54jmn3does it say what destructuring is?
22:01rhickeyI think so: "The basic idea is that a binding-form can be a data structure literal containing symbols that get bound to the respective parts of the init-expr"
22:12jmn3thats deep. gonna have to study that one. im in the midst of reading sicp.