Yes, I thought the same... Now, encouraged by Dave message ;-) some links: http://martinfowler.com/eaaDev/EventSourcing.html Dave mentioned CQRS, some post about Events, Event Sourcing AND CQRS: http://thinkbeforecoding.com/tag/CQRS
CQRS (Command Query Responsibility Separation) is a big topic, possibly not needed for this thread. Some tutorial, intro links I collected http://ajlopez.wordpress.com/2012/03/12/cqrs-links-news-and-resources-3-2/ On Wed, Jun 6, 2012 at 5:58 AM, Dave Sann <daves...@gmail.com> wrote: > This sounds a lot like Event Sourcing to me. (often coupled with CQRS). > > Which, I think, is similar to what datomic is doing, where: > - datom => event > - transactor => event store > - peer => query model > > There are a number of presentations, blogs available on this if you > haven't seen it previously. just Google for it > > It sounds simple in theory - and I like the idea a lot in principle - but > if you look at discussion boards, there seem to be challenges in actually > applying it effectively. Management and Synchronisation of separate write > and read model being significant. > > Dave > > On Wednesday, 6 June 2012 08:36:25 UTC+10, Kevin Lynagh wrote: >> >> Jonas, >> >> Definitely inspired by the ideas in Datomic. >> My question was partially: "how can I implement the core immutability >> semantics of Datomic in plain Clojure?". >> (Say, hypothetically, that I need a Clojure datastore with flexible >> schema and immutability semantics but cannot actually use Datomic for >> business reasons.) >> >> I gave it a shot this morning---writing code to serialize >> >> {:a 1 :b 2} >> >> into >> >> [#Assertion{:id 1, :attribute :a, :value 1, :time 0}, >> #Assertion{:id 1, :attribute :b, :value 2, :time 0}] >> >> and back again (which gets a bit more complex with references/ >> collections, but not much). >> >> Nicolas, >> >> Data can be kept anywhere that tuples can be kept = ) >> Caching intermediate values "diffs are collapsed" should definitely >> bring a speedup. >> The immutability semantics mean you really can go all out crazy with >> the caching too. >> >> >> >> On Jun 5, 1:44 am, "nicolas.o...@gmail.com" <nicolas.o...@gmail.com> >> wrote: >> > 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<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+unsubscribe@**googlegroups.com<clojure%2bunsubscr...@googlegroups.com> >> > > For more options, visit this group at >> > >http://groups.google.com/**group/clojure?hl=en<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 > -- 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
