It is not totally clear in your post how you want to keep the data? Is it in memory (with a transactional log somewhere)? If it is the case, you can do better than reducing the whole data set when executing a query: you can keep a cache of query results, or indexed data and maintain it, while still being purely functional. (For example by attaching those results as meta data to the data structure, and defining your own assoc-like functions that maintain a consistency of the meta-dataed query results)
On Tue, Jun 5, 2012 at 1:59 AM, Kevin Lynagh <ke...@keminglabs.com> wrote: > Has anyone seen or implemented a CRUD application in Clojure using a > database of immutable facts? > > For instance, a traditional database table supporting a todo-list > application has columns > > user_id, task_id, task_description, is_done > > A new row is created when a user adds a task. > Then that row is updated so is_done = TRUE when the user checks the > task off. > > With immutable facts this would instead be a collection of statements: > > User U added task T with description D at time T1 > User U completed task T at time T2 > > To get a list of unfinished tasks for a user, you'd need to grab all > the tasks from this "transaction log", put them into a data structure, > and then remove ones when you learn that they've been completed. > Whatever is left over is the todo list. > > Nathan Marz talked about this in terms of big data: > > http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html > > and Datomic's big bet is that your life as a developer gets much > easier when you just deal with (entity, attribute, value) + time. > > I buy it in theory, but I have no idea what to expect in terms of > performance (e.g., how long would it take to find the current todo > list of someone who has added and completed/removed a few thousand > items?). > > Has anyone implemented this idea on Clojure datastructures using, > say, (timestamp, keyseq, value) and reducing a ton of calls to assoc- > in? > Aside from speed, what are some other tradeoffs of an immutable > approach? > > -- > 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 -- Sent from an IBM Model M, 15 August 1989. -- 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
