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
> >
> > > 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
