#clojure log - Mar 18 2008

The Joy of Clojure
Main Clojure site
Google Group
IRC
List of all logged dates

1:15 arbscht: partial and comp put the fun in functional

11:38 Chouser: If 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:39 rhickey: is there a known granularity of change? is there an external notion of identity?

11:39 Chouser: at the very top? farther down at like a "table" level? Are there speed or contention issues I should be thinking about?

11:43 rhickey: contention rather than speed should drive it, speed should be fine in any case

11:44 I would avoid field-level refs

11:44 Chouser: I'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:44 right now I've got a ref for each of those top-level maps.

11:45 I was considering moving it up to the vector that holds that pair.

11:45 I'm not sure what you mean by external identity.

11:46 rhickey: outside of your app, there is a notion that a particular set of data can be identified by a key

11:47 if you are using triples, probably not an issue

11:47 Chouser: There 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:48 rhickey: more to do with object/record identity

11:49 if you are going to be heavily multithreaded with lots of updates, those top-level refs will be the bottleneck, if any

11:50 Chouser: ok, that makes sense.

11:50 And if I always update both at the same time, it won't help any to give each their own ref.

11:51 The 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:52 rhickey: right, you could then update the attribute set for a particular key independently

11:53 Chouser: I can still sync across multiple, though, to get "atomic" transations.

11:53 rhickey: exactly, that's the beauty of STM

11:53 arbitrary change sets

11:53 no lock ordering

11:54 Chouser: So I would expect this to have thousands of refs. That shouldn't scare me?

11:55 rhickey: not at all

11:55 Chouser: great.

11:55 I still don't know how I'm going to sync this to disk, but that's a problem for another day...

12:04 oh, but I'll need a ref at the top levels too, since of course you can add keys there.

12:07 rhickey: right but you'll only need to use them when you add/remove keys

20:18 jmn3: hi

20:22 ive 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:53 rhickey: It's destructuring - documented in the entry for let: http://clojure.sourceforge.net/reference/special_forms.html

21:53 jmn3: ok thanks

21:54 does it say what destructuring is?

22:01 rhickey: I 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:12 jmn3: thats deep. gonna have to study that one. im in the midst of reading sicp.

Logging service provided by n01se.net