On Tuesday, June 5, 2012 3:59:39 AM UTC+3, Kevin Lynagh 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 >
I think this would be a great fit for datomic. Consider the following transaction: [[;add entity :task/description "Make coffee"] [:add entity :task/deadline #inst ...] [:add entity :task/user user-entitiy]] In order to mark this todo item as "done" simply retract the entity: [[:retractEntity entity]] In addition, the :task/user attribute could be of type :db.cardinality/many so many users would be assigned to the same task. I bet it would also be possible to make a todo-item depend on another todo item and ask smart (declarative) queries like "What tasks has to be done before this task and who should do them?" > > 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
